aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel
AgeCommit message (Collapse)AuthorFilesLines
2018-05-22i40e: free skb after clearing lock in ptp_stopJacob Keller1-1/+3
Use the same logic to free the skb after clearing the Tx timestamp bit lock in i40e_ptp_stop as we use in the other locations. It is not as important here since we are not racing against a future Tx timestamp request (as we are disabling PTP at this point). However it is good to be consistent in how we approach the bit lock so that future callers don't copy the old anti-pattern. Signed-off-by: Jacob Keller <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-20Revert "ixgbe: release lock for the duration of ixgbe_suspend_close()"Jeff Kirsher1-8/+1
This reverts commit 6710f970d9979d8f03f6e292bb729b2ee1526d0e. Gotta love when developers have offline discussions, thinking everyone is reading their responses/dialog. The change had the potential for a number of race conditions on shutdown, which is why we are reverting the change. Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2018-05-17ice: Update NVM AQ command functionsAnirudh Venkataramanan2-9/+11
This patch updates the NVM read/erase/update AQ commands to align with the latest specification. Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Tony Brelinski <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-17ixgbevf: fix MAC address changes through ixgbevf_set_mac()Emil Tantilov1-0/+1
Set hw->mac.perm_addr in ixgbevf_set_mac() in order to avoid losing the custom MAC on reset. This can happen in the following case: >ip link set $vf address $mac >ethtool -r $vf Signed-off-by: Emil Tantilov <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-17ixgbe: force VF to grab new MAC on driver reloadEmil Tantilov1-4/+1
Do not validate the MAC address during a reset, unless the MAC was set on the host. This way the VF will get a new MAC address every time it reloads. Remove the "no MAC address assigned" message since it will get spammed on reset and it doesn't help much as the MAC on the VF is randomly generated. Signed-off-by: Emil Tantilov <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-17ixgbe: release lock for the duration of ixgbe_suspend_close()Pavel Tatashin1-1/+8
Currently, during device_shutdown() ixgbe holds rtnl_lock for the duration of lengthy ixgbe_close_suspend(). On machines with multiple ixgbe cards this lock prevents scaling if device_shutdown() function is multi-threaded. It is not necessary to hold this lock during ixgbe_close_suspend() as it is not held when ixgbe_close() is called also during shutdown but for kexec case. Signed-off-by: Pavel Tatashin <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2018-05-17ixgbe/ixgbevf: Free IRQ when PCI error recovery removes the deviceMauro S M Rodrigues2-6/+6
Since commit f7f37e7ff2b9 ("ixgbe: handle close/suspend race with netif_device_detach/present") ixgbe_close_suspend is called, from ixgbe_close, only if the device is present, i.e. if it isn't detached. That exposed a situation where IRQs weren't freed if a PCI error recovery system opts to remove the device. For such case the pci channel state is set to pci_channel_io_perm_failure and ixgbe_io_error_detected was returning PCI_ERS_RESULT_DISCONNECT before calling ixgbe_close_suspend consequentially not freeing IRQ and crashing when the remove handler calls pci_disable_device, hitting a BUG_ON at free_msi_irqs, which asserts that there is no non-free IRQ associated with the device to be removed: BUG_ON(irq_has_action(entry->irq + i)); The issue is fixed by calling the ixgbe_close_suspend before evaluate the pci channel state. Reported-by: Naresh Bannoth <[email protected]> Reported-by: Abdul Haleem <[email protected]> Signed-off-by: Mauro S M Rodrigues <[email protected]> Reviewed-by: Alexander Duyck <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
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]>