aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel
AgeCommit message (Collapse)AuthorFilesLines
2018-05-17ixgbe: cleanup sparse warningsCathy Zhou7-41/+55
Sparse complains valid conversions between restricted types, force attribute is used to avoid those warnings. Signed-off-by: Cathy Zhou <[email protected]> Reviewed-by: Shannon Nelson <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40evf: Fix a hardware reset support in VF driverPaweł Jabłoński2-3/+21
This patch fixes a hardware reset support in VF driver. It is needed because when a hardware reset is detected adapter->state is in __I40EVF_RESETTING state before i40evf_reset_task is called. Without this patch unloading VF driver after a hardware reset ends with a system crash. Signed-off-by: Paweł Jabłoński <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: free the skb after clearing the bitlockJacob Keller1-1/+6
In commit bbc4e7d273b5 ("i40e: fix race condition with PTP_TX_IN_PROGRESS bits") we modified the code which handles Tx timestamps so that we would clear the progress bit as soon as possible. A later commit 0bc0706b46cd ("i40e: check for Tx timestamp timeouts during watchdog") introduced similar code for detecting and handling cleanup of a blocked Tx timestamp. This code did not use the same pattern for cleaning up the skb. Update this code to wait to free the skb until after the bit lock is free, by first setting the ptp_tx_skb to NULL and clearing the lock. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: cleanup wording in a header commentJacob Keller1-1/+1
Fix up the English in the header comment for i40e_ptp_tx_hang. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40evf: remove MAX_QUEUES and just use I40EVF_MAX_REQ_QUEUESJacob Keller2-3/+3
We don't really need to have separate definitions for MAX_QUEUES and I40EVF_MAX_REQ_QUEUES, since we'll always be limited by how many queues we request anyways. If we haven't enabled requesting the maximum number of queues, there's no reason to have our call to alloc_etherdev_mq actually pass the higher value, since we'd never enable those queues anyways. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: add tx_busy to ethtool statsHarshitha Ramamurthy1-0/+1
This patch adds the tx_busy stat to the ethtool stats. The tx_busy stat tracks the number of times we return NETDEV_TX_BUSY to the stack during transmit. Signed-off-by: Harshitha Ramamurthy <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: Fix recalculation of MSI-X vectors for VMDqPatryk Małek1-4/+11
This patch adds a recalculation of number of MSI-X vectors for VMDq in the case where we have less vectors available than we would want to reserve for VMDq. It fixes the issue where we recalculate vectors left and vectors wanted but we didn't take into account the reduced number of queue pairs per VSI. Signed-off-by: Patryk Małek <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: cleanup whitespace for some ethtool stat definitionsJacob Keller1-6/+6
A future patch is going to refactor some of the ethtool statistic code. To keep the patches easy to review, cleanup some of the indentation used for macro definitions first. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: remove duplicate pfc statsJacob Keller1-4/+0
The pfc related priority stats are already handled separately as these stats are actually arrays of length I40E_MAX_USER_PRIORITY. Thus, including them within i40e_gstrings_stats will just duplicate data. Worse, the sizeof will be incorrect, as it will be the total size of the stat arrays, which in this case is 8 * sizeof(u64), so we will only copy the stat contents as if they were a u32. Since we already correctly handle these stats else where, remove them from the i40e_gstrings_stats. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40e: calculate ethtool stats size in a separate functionJacob Keller1-10/+18
Use a separate function to calculate the number of stats for a particular device. This helps reduce the clutter in i40e_get_sset_count(). Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-14i40evf: Fix client header defineJeff Kirsher1-3/+3
Fix up the VF client header define, since it is the same as the PF client header. Signed-off-by: Jeff Kirsher <[email protected]> Tested-by: Andrew Bowers <[email protected]>
2018-05-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller4-3/+6
The bpf syscall and selftests conflicts were trivial overlapping changes. The r8169 change involved moving the added mdelay from 'net' into a different function. A TLS close bug fix overlapped with the splitting of the TLS state into separate TX and RX parts. I just expanded the tests in the bug fix from "ctx->conf == X" into "ctx->tx_conf == X && ctx->rx_conf == X". Signed-off-by: David S. Miller <[email protected]>
2018-05-11ixgbe: fix memory leak on ipsec allocationColin Ian King1-1/+1
The error clean up path kfree's adapter->ipsec and should be instead kfree'ing ipsec. Fix this. Also, the err1 error exit path does not need to kfree ipsec because this failure path was for the failed allocation of ipsec. Detected by CoverityScan, CID#146424 ("Resource Leak") Fixes: 63a67fe229ea ("ixgbe: add ipsec offload add and remove SA") Signed-off-by: Colin Ian King <[email protected]> Acked-by: Shannon Nelson <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-11ixgbevf: fix ixgbevf_xmit_frame()'s return typeLuc Van Oostenryck1-1/+1
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, but the implementation in this driver returns an 'int'. Fix this by returning 'netdev_tx_t' in this driver too. Signed-off-by: Luc Van Oostenryck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-11ixgbe: return error on unsupported SFP module when resettingEmil Tantilov1-0/+3
Add check for unsupported module and return the error code. This fixes a Coverity hit due to unused return status from setup_sfp. Signed-off-by: Emil Tantilov <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-11ice: Set rq_last_status when cleaning rqJeff Shaw1-1/+1
Prior to this commit, the rq_last_status was only set when hardware responded with an error. This leads to rq_last_status being invalid in the future when hardware eventually responds without error. This commit resolves the issue by unconditionally setting rq_last_status with the value returned in the descriptor. Fixes: 940b61af02f4 ("ice: Initialize PF and setup miscellaneous interrupt") Signed-off-by: Jeff Shaw <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Tony Brelinski <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-09fm10k: don't protect fm10k_queue_mac_request by fm10k_host_mbx_readyJacob Keller1-8/+8
We don't actually need to check if the host mbx is ready when queuing MAC requests, because these are not handled by a special queue which queues up requests until the mailbox is capable of handling them. Pull these requests outside the fm10k_host_mbx_ready() check, as it is not necessary. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-09fm10k: warn if the stat size is unknownJacob Keller1-0/+2
Signed-off-by: Jacob Keller <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-09fm10k: use macro to avoid passing the array and size separatelyJacob Keller1-27/+21
Avoid potential bugs with fm10k_add_stat_strings and fm10k_add_ethtool_stats by using a macro to calculate the ARRAY_SIZE when passing. This helps ensure that the size is always correct. Note that it assumes we only pass static const fm10k_stat arrays, and that evaluation of the argument won't have side effects. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-09fm10k: use variadic arguments to fm10k_add_stat_stringsJacob Keller1-26/+27
Instead of using a fixed prefix string we setup before each call to fm10k_add_stat_strings, modify the helper to take variadic arguments and pass them to vsnprintf. This requires changing the fm10k_stat strings to take % format specifiers where necessary, but the resulting code is much simpler. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-09fm10k: reduce duplicate fm10k_stat macro codeJacob Keller1-14/+15
Share some of the code for setting up fm10k_stat macros by implementing an FM10K_STAT_FIELDS macro which we can use when setting up the type specific macros. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-09fm10k: setup VLANs for l2 accelerated macvlan interfacesJacob Keller1-2/+48
We have support for accelerating macvlan devices via the .ndo_dfwd_add_station() netdev op. These accelerated macvlan MAC addresses are stored in the l2_accel structure, separate from the unicast or multicast address lists. If a VLAN is added on top of the macvlan device by the stack, traffic will not properly flow to the macvlan. This occurs because we fail to setup the VLANs for l2_accel MAC addresses. In the non-offloaded case the MAC address is added to the unicast address list, and thus the normal setup for enabling VLANs works as expected. We also need to add VLANs marked from .ndo_vlan_rx_add_vid() into the l2_accel MAC addresses. Otherwise, VLAN traffic will not properly be received by the VLAN devices attached to the offloaded macvlan devices. Fix this by adding necessary logic to setup VLANs not only for the unicast and multicast addresses, but also the l2_accel list. We need similar logic in dfwd_add_station, dfwd_del_station, fm10k_update_vid, and fm10k_restore_rx_state. Signed-off-by: Jacob Keller <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e: use %pI4b instead of byte swapping before dev_errJacob Keller1-4/+2
Fix warnings regarding restricted __be32 type usage by strictly specifying the type of the ipv4 address being printed in the dev_err statement. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e/i40evf: take into account queue map from vf when handling queuesHarshitha Ramamurthy3-13/+99
The expectation of the ops VIRTCHNL_OP_ENABLE_QUEUES and VIRTCHNL_OP_DISABLE_QUEUES is that the queue map sent by the VF is taken into account when enabling/disabling queues in the VF VSI. This patch makes sure that happens. By breaking out the individual queue set up functions so that they can be called directly from the i40e_virtchnl_pf.c file, only the queues as specified by the queue bit map that accompanies the enable/disable queues ops will be handled. Signed-off-by: Harshitha Ramamurthy <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e: avoid overflow in i40e_ptp_adjfreq()Jacob Keller2-15/+28
When operating at 1GbE, the base incval for the PTP clock is so large that multiplying it by numbers close to the max_adj can overflow the u64. Rather than attempting to limit the max_adj to a value small enough to avoid overflow, instead calculate the incvalue adjustment based on the 40GbE incvalue, and then multiply that by the scaling factor for the link speed. This sacrifices a small amount of precision in the adjustment but we avoid erratic behavior of the clock due to the overflow caused if ppb is very near the maximum adjustment. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e: Fix multiple issues with UDP tunnel offload filter configurationAlexander Duyck2-12/+56
This fixes at least 2 issues I have found with the UDP tunnel filter configuration. The first issue is the fact that the tunnels didn't have any sort of mutual exclusion in place to prevent an update from racing with a user request to add/remove a port. As such you could request to add and remove a port before the port update code had a chance to respond which would result in a very confusing result. To address it I have added 2 changes. First I added the RTNL mutex wrapper around our updating of the pending, port, and filter_index bits. Second I added logic so that we cannot use a port that has a pending deletion since we need to free the space in hardware before we can allow software to reuse it. The second issue addressed is the fact that we were not recording the actual filter index provided to us by the admin queue. As a result we were deleting filters that were not associated with the actual filter we wanted to delete. To fix that I added a filter_index member to the UDP port tracking structure. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40evf: Fix turning TSO, GSO and GRO on afterPaweł Jabłoński1-0/+18
This patch fixes the problem where each MTU change turns TSO, GSO and GRO on from off state. Now when TSO, GSO or GRO is turned off, MTU change does not turn them on. Signed-off-by: Paweł Jabłoński <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e: Add advertising 10G LR modeJakub Pawlak1-1/+3
The advertising 10G LR mode should be possible to set but in the function i40e_set_link_ksettings() check for this is missed. This patch adds check for 10000baseLR_Full flag for 10G modes. Signed-off-by: Jakub Pawlak <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e: fix reading LLDP configurationMariusz Stachura3-10/+99
Previous method for reading LLDP config was based on hard-coded offsets. It happened to work, because of structured architecture of the NVM memory. In the new approach, known as FLAT, we need to calculate the absolute address, instead of using relative values. Needed defines for memory location were added. Signed-off-by: Mariusz Stachura <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40e/i40evf: cleanup incorrect function doxygen commentsJacob Keller17-73/+95
Recent versions of the Linux kernel now warn about incorrect parameter definitions for function comments. Fix up several function comments to correctly reflect the current function arguments. This cleans up the warnings and helps ensure our documentation is accurate. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-30i40evf: Replace GFP_ATOMIC with GFP_KERNEL in i40evf_add_vlanJia-Ju Bai1-1/+1
i40evf_add_vlan() is never called in atomic context. i40evf_add_vlan() is only called by i40evf_vlan_rx_add_vid(), which is only set as ".ndo_vlan_rx_add_vid" in struct net_device_ops. ".ndo_vlan_rx_add_vid" is not called in atomic context. Despite never getting called from atomic context, i40evf_add_vlan() calls kzalloc() with GFP_ATOMIC, which does not sleep for allocation. GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL, which can sleep and improve the possibility of sucessful allocation. This is found by a static analysis tool named DCNS written by myself. And I also manually check it. Signed-off-by: Jia-Ju Bai <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-27net: intel: Cleanup the copyright/license headersJeff Kirsher195-4624/+222
After many years of having a ~30 line copyright and license header to our source files, we are finally able to reduce that to one line with the advent of the SPDX identifier. Also caught a few files missing the SPDX license identifier, so fixed them up. Signed-off-by: Jeff Kirsher <[email protected]> Acked-by: Shannon Nelson <[email protected]> Acked-by: Richard Cochran <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-04-25Merge branch '1GbE' of ↵David S. Miller4-15/+439
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2018-04-25 This series enables some ethtool and tc-flower filters to be offloaded to igb-based network controllers. This is useful when the system configuration wants to steer kinds of traffic to a specific hardware queue for i210 devices only. The first two patch in the series are bug fixes. The basis of this series is to export the internal API used to configure address filters, so they can be used by ethtool, and extending the functionality so an source address can be handled. Then, we enable the tc-flower offloading implementation to re-use the same infrastructure as ethtool, and storing them in the per-adapter "nfc" (Network Filter Config?) list. But for consistency, for destructive access they are separated, i.e. an filter added by tc-flower can only be removed by tc-flower, but ethtool can read them all. Only support for VLAN Prio, Source and Destination MAC Address, and Ethertype is enabled for now. ==================== Signed-off-by: David S. Miller <[email protected]>
2018-04-25igb: Add support for adding offloaded clsflower filtersVinicius Costa Gomes2-2/+188
This allows filters added by tc-flower and specifying MAC addresses, Ethernet types, and the VLAN priority field, to be offloaded to the controller. This reuses most of the infrastructure used by ethtool, but clsflower filters are kept in a separated list, so they are invisible to ethtool. To setup clsflower offloading: $ tc qdisc replace dev eth0 handle 100: parent root mqprio \ num_tc 3 map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ queues 1@0 1@1 2@2 hw 0 (clsflower offloading depends on the netword driver to be configured with multiple traffic classes, we use mqprio's 'num_tc' parameter to set it to 3) $ tc qdisc add dev eth0 ingress Examples of filters: $ tc filter add dev eth0 parent ffff: flower \ dst_mac aa:aa:aa:aa:aa:aa \ hw_tc 2 skip_sw (just a simple filter filtering for the destination MAC address and steering that traffic to queue 2) $ tc filter add dev enp2s0 parent ffff: proto 0x22f0 flower \ src_mac cc:cc:cc:cc:cc:cc \ hw_tc 1 skip_sw (as the i210 doesn't support steering traffic based on the source address alone, we need to use another steering traffic, in this case we are using the ethernet type (0x22f0) to steer traffic to queue 1) Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Add the skeletons for tc-flower offloadingVinicius Costa Gomes1-0/+66
This adds basic functions needed to implement offloading for filters created by tc-flower. Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Add MAC address support for ethtool nftuple filtersVinicius Costa Gomes1-4/+39
This adds the capability of configuring the queue steering of arriving packets based on their source and destination MAC addresses. Source address steering (i.e. driving traffic to a specific queue), for the i210, does not work, but filtering does (i.e. accepting traffic based on the source address). So, trying to add a filter specifying only a source address will be an error. In practical terms this adds support for the following use cases, characterized by these examples: $ ethtool -N eth0 flow-type ether dst aa:aa:aa:aa:aa:aa action 0 (this will direct packets with destination address "aa:aa:aa:aa:aa:aa" to the RX queue 0) $ ethtool -N eth0 flow-type ether src 44:44:44:44:44:44 \ proto 0x22f0 action 3 (this will direct packets with source address "44:44:44:44:44:44" and ethertype 0x22f0 to the RX queue 3) Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Enable nfc filters to specify MAC addressesVinicius Costa Gomes2-0/+32
This allows igb_add_filter()/igb_erase_filter() to work on filters that include MAC addresses (both source and destination). For now, this only exposes the functionality, the next commit glues ethtool into this. Later in this series, these APIs are used to allow offloading of cls_flower filters. Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Allow filters to be added for the local MAC addressVinicius Costa Gomes1-4/+36
Users expect that when adding a steering filter for the local MAC address, that all the traffic directed to that address will go to some queue. Currently, it's not possible to configure entries in the "in use" state, which is the normal state of the local MAC address entry (it is the default), this patch allows to override the steering configuration of "in use" entries, if the filter to be added match the address and address type (source or destination) of an existing entry. There is a bit of a special handling for entries referring to the local MAC address, when they are removed, only the steering configuration is reset. Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Add support for enabling queue steering in filtersVinicius Costa Gomes3-0/+33
On some igb models (82575 and i210) the MAC address filters can control to which queue the packet will be assigned. This extends the 'state' with one more state to signify that queue selection should be enabled for that filter. As 82575 parts are no longer easily obtained (and this was developed against i210), only support for the i210 model is enabled. These functions are exported and will be used in the next patch. Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Add support for MAC address filters specifying source addressesVinicius Costa Gomes3-5/+37
Makes it possible to direct packets to queues based on their source address. Documents the expected usage of the 'flags' parameter. Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Enable the hardware traffic class feature bit for igb modelsVinicius Costa Gomes1-0/+3
This will allow functionality depending on the hardware being traffic class aware to work. In particular the tc-flower offloading checks verifies that this bit is set. Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Fix queue selection on MAC filters on i210Vinicius Costa Gomes1-2/+7
On the RAH registers there are semantic differences on the meaning of the "queue" parameter for traffic steering depending on the controller model: there is the 82575 meaning, which "queue" means a RX Hardware Queue, and the i350 meaning, where it is a reception pool. The previous behaviour was having no effect for i210 based controllers because the QSEL bit of the RAH register wasn't being set. This patch separates the condition in discrete cases, so the different handling is clearer. Fixes: 83c21335c876 ("igb: improve MAC filter handling") Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25igb: Fix not adding filter elements to the listVinicius Costa Gomes1-1/+1
Because the order of the parameters passes to 'hlist_add_behind()' was inverted, the 'parent' node was added "behind" the 'input', as input is not in the list, this causes the 'input' node to be lost. Fixes: 0e71def25281 ("igb: add support of RX network flow classification") Signed-off-by: Vinicius Costa Gomes <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25ixgbe: Avoid performing unnecessary resets for macvlan offloadAlexander Duyck2-62/+135
The original implementation for macvlan offload has us performing a full port reset every time we added a new macvlan. This shouldn't be necessary and can be avoided with a few behavior changes. This patches updates the logic for the queues so that we have essentially 3 possible configurations for macvlan offload. They consist of 15 macvlans with 4 queues per macvlan, 31 macvlans with 2 queues per macvlan, and 63 macvlans with 1 queue per macvlan. As macvlans are added you will encounter up to 3 total resets if you add all the way up to 63, and after that the device will stay in the mode supporting up to 63 macvlans until the L2FW flag is cleared. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25ixgbe: Drop real_adapter from l2 fwd acceleration structureAlexander Duyck2-13/+16
This patch drops the real_adapter member from the fwd_adapter structure. The general idea behind the change is that the real_adapter is carrying unnecessary data since we could always just grab the adapter structure from netdev_priv(macvlan->lowerdev) if we really needed to get at it. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25ixgbe/fm10k: Only support macvlan offload for types that support destination ↵Alexander Duyck2-0/+15
filtering Both the ixgbe and fm10k drivers support destination filtering. Instead of adding a ton of complexity to support either source or passthru mode we can instead just avoid offloading them for now. Doing this we avoid leaking packets into interfaces that aren't meant to receive them. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25ixgbe/fm10k: Drop tracking stats for macvlan broadcast/multicastAlexander Duyck2-8/+6
Drop dead code now that we shouldn't be receiving broadcast or multicast frames on the queues associated to the macvlan netdev. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25macvlan: Use software path for offloaded local, broadcast, and multicast trafficAlexander Duyck2-31/+12
This change makes it so that we use a software path for packets that are going to be locally switched between two macvlan interfaces on the same device. In addition we resort to software replication of broadcast and multicast packets instead of offloading that to hardware. The general idea is that using the device for east/west traffic local to the system is extremely inefficient. We can only support up to whatever the PCIe limit is for any given device so this caps us at somewhere around 20G for devices supported by ixgbe. This is compounded even further when you take broadcast and multicast into account as a single 10G port can come to a crawl as a packet is replicated up to 60+ times in some cases. In order to get away from that I am implementing changes so that we handle broadcast/multicast replication and east/west local traffic all in software. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25macvlan: Rename fwd_priv to accel_priv and add accessor functionAlexander Duyck1-6/+4
This change renames the fwd_priv member to accel_priv as this more accurately reflects the actual purpose of this value. In addition I am adding an accessor which will allow us to further abstract this in the future if needed. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-04-25ixgbe: Drop support for macvlan specific unicast listsAlexander Duyck1-31/+0
Drop the code for handling macvlan specific unicast lists. It isn't needed since we don't take any efforts to maintain it when we bring the interface up and it takes the slow path anyway. Signed-off-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>