summaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/intel
Commit message (Collapse)AuthorAgeFilesLines
...
| * | i40e: Reprogram port offloads after resetAlexander Duyck2017-04-301-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corrects a major oversight in that we were not reprogramming the ports after a reset. As a result we completely lost all of the Rx tunnel offloads on receive including Rx checksum, RSS on inner headers, and ATR. The fix for this is pretty standard as all we needed to do is reset the filter bits to pending for all active filters and schedule the sync event. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: rename index to port to avoid confusionJacob Keller2017-04-302-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | The .index field of i40e_udp_port_config represents the udp port number. Rename this variable to port so that it is more obvious. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: make use of i40e_reset_all_vfs when initializing new VFsJacob Keller2017-04-302-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When allocating a large number of VFs, the driver previously used i40e_reset_vf in a sequence. Just as when performing a normal reset, this accumulates a large amount of delay for handling all of the VFs in sequence. This delay is mainly due to a hardware requirement to wait after initiating a reset on the VF. We recently added a new function, i40e_reset_all_vfs() which can be used to amortize the delay time, by first triggering all VF resets, then waiting once, and finally cleaning up and allocating the VFs. This is almost as good as truly running the resets in parallel. In order to avoid sending a spurious reset message to a client interface, we have a check to see whether we've assigned pf->num_alloc_vfs yet. This was originally intended as a way to distinguish the "initialization" case from the regular reset case. Unfortunately, this means that we can't directly use i40e_reset_all_vfs yet. Lets avoid this check of pf->num_alloc_vfs by replacing it with a proper VSI state bit which we can use instead. This makes the intention much clearer and allows us to re-use the i40e_reset_all_vfs function directly. Change-ID: I694279b37eb6b5a91b6670182d0c15d10244fd6e Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: properly spell I40E_VF_STATE_* flagsJacob Keller2017-04-304-58/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These flags represent the state of the VF at various times. Do not spell them as _STAT_ which can be confusing to readers who may think these refer to statistics. Change-ID: I6bc092cd472e8276896a1fd7498aced2084312df Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | e1000e: Add Support for 38.4MHZ frequencySasha Neftin2017-04-302-29/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for 38.4MHz frequency is required for PTP on CannonLake. SYSTIM frequency adjustment attributes for TIMINCA are get/set dependent on the hardware clock frequency for a different types of adapters. 38.4MHz frequency supported by CannonLake and active once time synchronisation mechanism was enabled Changed abbreviation from Hz to HZ to be compliant checkpatch code style Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Reviewed-by: Raanan Avargil <raanan.avargil@intel.com> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | e1000e: Add Support for CannonLakeSasha Neftin2017-04-304-62/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The propagation of CannonLake mac type to driver functionality Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Reviewed-by: Raanan Avargil <raanan.avargil@intel.com> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | e1000e: Initial Support for CannonLakeSasha Neftin2017-04-304-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i219 (6) and i219 (7) are the next LOM generations that will be available on the nextIntel Client platform (CannonLake) This patch provides the initial support for these devices Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Reviewed-by: Raanan Avargil <raanan.avargil@intel.com> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | e1000e: fix PTP on e1000_pch_lpt variantsJarod Wilson2017-04-301-1/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used as a PTP slave experiences random ~10 hour clock jumps, which are resolved if the same workaround for the 82574 and 82583 is employed, so set the appropriate flag2 in e1000_pch_lpt_info too. Reported-by: Rupesh Patel <rupatel@redhat.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbevf: Check for RSS key before setting valueTony Nguyen2017-04-303-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The RSS key is being repopulated every time the interface is brought up regardless of whether there is an existing value. If the user sets the RSS key and the interface is brought up (e.g. reset), the user specified RSS key will be overwritten. This patch changes the rss_key to a pointer so we can check to see if the key has been populated and preserve it accordingly. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbevf: Fix errors in retrieving RETA and RSS from PFTony Nguyen2017-04-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mailbox support for getting RETA and RSS is available for only 82599 and x540; a previous patch reversed the logic and these adapters were returning not supported. Also, the NACK check in ixgbevf_get_rss_key_locked() was checking for the command IXGBE_VF_GET_RETA instead of IXGBE_VF_GET_RSS_KEY. This patch corrects both issues by correcting the logic and checking for the right command. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: Check for RSS key before setting valueTony Nguyen2017-04-304-7/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The RSS key is being repopulated every time the interface is brought up regardless of whether there is an existing value. If the user sets the RSS key and the interface is brought up (e.g. reset), the user specified RSS key will be overwritten. This patch changes the rss_key to a pointer so we can check to see if the key has been populated and preserve it accordingly. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: Add 1000Base-T device based on X550EM_X MACPaul Greenwalt2017-04-304-1/+49
| | | | | | | | | | | | | | | | | | | | Add support for new 1000Base-T device based on X550EM_X MAC type. All PHY operations are disabled as the PHY is controlled by FW. Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: Allow setting zero MAC address for VFTony Nguyen2017-04-301-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no logic that allows a VF's MAC address to be removed from the RAR table. Allow the user to specify a zero MAC address in order to clear the VF's MAC address from the RAR table. This functionality is also utilized by libvirt when removing VFs. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbevf: fix size of queue stats lengthEmil Tantilov2017-04-301-1/+1
| | | | | | | | | | | | | | | | | | | | IXGBEVF_QUEUE_STATS_LEN is based on ixgebvf_stats, not ixgbe_stats. This change fixes a bug where ethtool -S displayed some empty fields. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: clean macvlan MAC filter table on VF resetEmil Tantilov2017-04-301-52/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flush the macvlan filters on VF reset to avoid conflict with other VFs that may end up using the same MAC address. The main change here is the call to ixgbe_set_vf_macvlan() with index 0. Moved ixgbe_set_vf_macvlan() in front of ixgbe_vf_reset_event() to avoid adding a prototype. Reported-by: Sritej Kanakadandi Sritej Rama <skanakad@cisco.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: delay tail write to every 'n' packetsJohn Fastabend2017-04-301-11/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Current XDP implementation hits the tail on every XDP_TX return code. This patch changes driver behavior to only hit the tail after packet processing is complete. With this patch I can run XDP drop programs @ 14+Mpps and XDP_TX programs are at ~13.5Mpps. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: add support for XDP_TX actionJohn Fastabend2017-04-304-53/+348
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A couple design choices were made here. First I use a new ring pointer structure xdp_ring[] in the adapter struct instead of pushing the newly allocated XDP TX rings into the tx_ring[] structure. This means we have to duplicate loops around rings in places we want to initialize both TX rings and XDP rings. But by making it explicit it is obvious when we are using XDP rings and when we are using TX rings. Further we don't have to do ring arithmatic which is error prone. As a proof point for doing this my first patches used only a single ring structure and introduced bugs in FCoE code and macvlan code paths. Second I am aware this is not the most optimized version of this code possible. I want to get baseline support in using the most readable format possible and then once this series is included I will optimize the TX path in another series of patches. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: add XDP support for pass and drop actionsJohn Fastabend2017-04-303-29/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | Basic XDP drop support for ixgbe. Uses READ_ONCE/xchg semantics on XDP programs instead of RCU primitives as suggested by Daniel Borkmann and Alex Duyck. v2: fix the build issues seen w/ XDP when page sizes are larger than 4K and made minor fixes based on feedback from Jakub Kicinski Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | ixgbe: Acquire PHY semaphore before device resetPaul Greenwalt2017-04-292-0/+16
| | | | | | | | | | | | | | | | | | | | | | A recent firmware change fixed an issue to acquire the PHY semaphore before accessing PHY registers. This led to a case where SW can issue a device reset clearing the MDIO registers. This patch makes SW acquire the PHY semaphore before issuing a device reset. Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | Merge branch '1GbE' of ↵David S. Miller2017-04-2412-134/+499
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2017-04-20 This series contains updates to e1000, e1000e, igb/vf and ixgb. Tobias Klauser cleans up e1000, ixgb and igbvf from having a local function or structure for netdev stats. Bernd Faust fixes an issue for 82579 devices, where the clock frequency was being incorrectly set for these devices. These devices only support 96MHz, so make sure they are set to use only that. Yury Kylulin extends the work Jake and Alex did for ixgbe in MAC filter handling into the igb driver. Kim Tatt Chuah enables igb to wake up by packet and to read the necessary Wake Up Status (WUS) and Wake Up Packet Memory (WUPM) registers. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | igbvf: Use net_device_stats from struct net_deviceTobias Klauser2017-04-212-22/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a private copy of struct net_device_stats in struct igbvf_adapter, use stats from struct net_device. Also remove the now unnecessary .ndo_get_stats function. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | igb: Enable reading of wake up packetKim Tatt Chuah2017-04-212-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, in igb_resume(), igb driver ignores the Wake Up Status (WUS) and Wake Up Packet Memory (WUPM) registers. This patch enables the igb driver to read the WUPM if the controller was woken by a wake up packet that is not more than 128 bytes long (maximum WUPM size), then pass it up the kernel network stack. Signed-off-by: Kim Tatt Chuah <kim.tatt.chuah@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | igb/igbvf: Add VF MAC filter request capabilitiesYury Kylulin2017-04-218-15/+240
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functionality for the VF to request up to 3 additional MAC filters. This is done using existing E1000_VF_SET_MAC_ADDR message, but with additional message info - E1000_VF_MAC_FILTER_CLR to clear all unicast MAC filters previously set for this VF and E1000_VF_MAC_FILTER_ADD to add MAC filter. Additional filters can be added only in case if administrator did not set VF MAC explicitly and allowed to change default MAC to the VF. Due to the limited number of RAR entries reserve at least 3 MAC filters for the PF. If SRIOV is supported by the NIC after this change RAR entries starting from 1 to (RAR MAX ENTRIES - NUM SRIOV VFS) will be used for PF and VF MAC filters. Signed-off-by: Yury Kylulin <yury.kylulin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | igb: improve MAC filter handlingYury Kylulin2017-04-212-65/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the work which was done for ixgbe driver by Jacob Keller commit 5d7daa35b9eb ("ixgbe: improve mac filter handling") and Alexander Duyck commit 0f079d22834a ("ixgbe: Use __dev_uc_sync and __dev_uc_unsync for unicast addresses") and out-of-tree igb driver add functionality to manage (add and delete) MAC filters. Signed-off-by: Yury Kylulin <yury.kylulin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | e1000e: fix timing for 82579 Gigabit Ethernet controllerBernd Faust2017-04-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After an upgrade to Linux kernel v4.x the hardware timestamps of the 82579 Gigabit Ethernet Controller are different than expected. The values that are being read are almost four times as big as before the kernel upgrade. The difference is that after the upgrade the driver sets the clock frequency to 25MHz, where before the upgrade it was set to 96MHz. Intel confirmed that the correct frequency for this network adapter is 96MHz. Signed-off-by: Bernd Faust <berndfaust@gmail.com> Acked-by: Sasha Neftin <sasha.neftin@intel.com> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | ixgb: Omit private ndo_get_stats functionTobias Klauser2017-04-211-16/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ixgb_get_stats() just returns dev->stats so we can leave it out altogether and let dev_get_stats() do the job. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | e1000: Omit private ndo_get_stats functionTobias Klauser2017-04-211-15/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | e1000_get_stats() just returns dev->stats so we can leave it out altogether and let dev_get_stats() do the job. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | Merge branch '40GbE' of ↵David S. Miller2017-04-2127-187/+1625
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2017-04-19 This series contains updates to i40e and i40evf only, most notable being the addition of trace points for BPF programs. Tobias Klauser updates i40evf to use net_device stats struct instead of a local private copy. Preethi updates the VF driver to not enable receive checksum offload by default for tunneled packets. Alex fixes an issue he introduced when he converted the code over to using the length field to determine if a descriptor was done or not. Mitch adds the ability to dump additional information on the VFs, which is not available through 'ip link show' using debugfs. Scott adds trace points to the drivers so that BPF programs can be attached for feature testing and verification. Jingjing adds admin queue functions for Pipeline Personalization Profile commands. Jake does most of the heavy lifting in this series, starting with the a reduction in the scope of the RTNL lock being held while resetting VFs to allow multiple PFs to reset in a timely manner. Factored out the direct queue modification so that we are able to re-use the code. Reduced the wait time for admin queue commands to complete, since we were waiting a minimum of a millisecond, when in practice the admin queue command is processed often much faster. Cleaned up code (flag) we never use. Make the code to resetting all the VFs optimized for parallel computing instead of the current way is a serialized fashion, to help reduce the time it takes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * | i40e: use i40e_stop_rings_no_wait to implement PORT_SUSPENDED stateJacob Keller2017-04-202-11/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This state bit was added as a way for DCB to avoid having to wait for the queues to disable when handling LLDP events. The logic for this was burried deep within stop Tx and stop Rx queue code. First, let's rename it so that it does not appear to only affect Tx when infact it modifies both Tx and Rx flow. Second we can move it up into the i40e_stop_rings() function, and we can simply re-use the i40e_stop_rings_no_wait() so that we don't have to bury the implementation as deep into the call stack. An alternative might be to remove the state bit and instead attempt to shut down everything directly in DCP flow. This, however, is not ideal because it creates yet another separate shutdown routine that we'd have to maintain. In the current implementation any changes will be made to both flows. Change-ID: I68e1ccb901af320862bca395e9c9746f08e8b17c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: reset all VFs in parallel when rebuilding PFJacob Keller2017-04-204-6/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When there are a lot of active VFs, it can take multiple seconds to finish resetting all of them during certain flows., which can cause some VFs to fail to wait long enough for the reset to occur. The user might see messages like "Never saw reset" or "Reset never finished" and the VF driver will stop functioning properly. The naive solution would be to simply increase the wait timer. We can get much more clever. Notice that i40e_reset_vf is run in a serialized fashion, and includes lots of delays. There are two prominent delays which take most of the time. First, when we begin resetting VFs, we have multiple 10ms delays which accrue because we reset each VF in a serial fashion. These delays accumulate to almost 4 seconds when handling the maximum number of VFs (128). Secondly, there is a massive 50ms delay for each time we disable queues on a VSI. This delay is necessary to allow HW to finish disabling queues before we restore functionality. However, just like with the first case, we are paying the cost for each VF, rather than disabling all VFs and waiting once. Both of these can be fixed, but required some previous refactoring to handle the special case. First, we will need the i40e_vsi_wait_queues_disabled function which was previously DCB specific. Second, we will need to implement our own i40e_vsi_stop_rings_no_wait function which will handle the stopping of rings without the delays. Finally, implement an i40e_reset_all_vfs function, which will first start the reset of all VFs, and pay the wait cost all at once, rather than serially waiting for each VF before we start processing then next one. After the VF has been reset, we'll disable all the VF queues, and then wait for them to disable. Again, we'll organize the flow such that we pay the wait cost only once. Finally, after we've disabled queues we'll go ahead and begin restoring VF functionality. The result is reducing the wait time by a large factor and ensuring that VFs do not timeout when waiting in the VF driver. Change-ID: Ia6e8cf8d98131b78aec89db78afb8d905c9b12be Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: split some code in i40e_reset_vf into helpersJacob Keller2017-04-201-37/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A future patch is going to want to re-use some of the code in i40e_reset_vf, so lets break up the beginning and ending parts into their own helper functions. The first function will be used to initialize the reset on a VF, while the second function will be used to finalize the reset and restore functionality. Change-ID: I48df808b8bf09de3c2ed8c521f57b3f0ab9e5907 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: remove I40E_FLAG_IN_NETPOLL entirelyJacob Keller2017-04-201-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This flag was originally intended to be used to let some driver code know when we were running from netpoll. Ultimately this was not necessary and we never used it. Let's remove it Change-ID: I43b72483d91c1638071d2a7f389ab171ec5b796a Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: reduce wait time for adminq command completionJacob Keller2017-04-204-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When sending an adminq command, we wait for the command to complete in a loop. This loop waits for an entire millisecond, when in practice the adminq command is processed often much faster. Change the loop to use i40e_usec_delay instead, and wait for 50 usecs each time instead. This appears to be about the minimum time required, based on some manual observation and testing. The primary benefit of this change is reducing latency of various operations in the PF driver, especially when related to having a large number of VFs enabled. For example, on Linux, when instantiating 128 VFs, the time to finish the operation dropped from about 9 seconds down to under 6 seconds. Additionally, the time it takes to finish a PF reset with 128 VFs dropped from 5.1 seconds down to 0.7 seconds. As the examples above show, a significant portion of the delay is wasted waiting for admiqn operations which have already finished. This patch shouldn't cause impact to functionality, as we still check and keep waiting until the command does get processed. The only expected change is an increase in CPU utilization as we now check for completion far more times. However, in practice the commands appear to generally be complete within the first delay window anyways. Change-ID: If8af8388e100da0a14eaf9e1af3afadf73a958cf Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: fix CONFIG_BUSY checks in i40e_set_settings functionJacob Keller2017-04-201-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The check for I40E_CONFIG_BUSY state bit in the i40e_set_link_ksettings function is fishy. First we can notice a few things about the check here. First a similar check was introduced by commit 'c7d05ca89f8e ("i40e: driver ethtool core")' Later a commit introducing the link settings was added by commit 'bf9c71417f72 ("i40e: Implement set_settings for ethtool")' However, this second check was against vsi->state instead of pf->state, and also failed to set the bit, it only checks. That indicates the locking was not quite correct. The only other place that the state bit in vsi->state gets used is to protect the filter list. Since this code does not care about the mac filter list, and seems clear the original code should have set the pf->state bit. Fix these issues by using pf->state correctly, and by actually setting the bit so that we properly lock as expected. Since these checks occur while holding the rtnl_lock(), lets also add a timeout so that we don't potentially softlock the system. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: factor out queue control from i40e_vsi_control_(tx|rx)Jacob Keller2017-04-201-50/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A future patch will need to be able to handle controlling queues without waiting until all VSIs are handled. Factor out the direct queue modification so that we can easily re-use this code. The result is also a bit easier to read since we don't embed multiple single-letter loop counters. Change-ID: Id923cbfa43127b1c24d8ed4f809b1012c736d9ac Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: don't hold RTNL lock while waiting for VF reset to finishJacob Keller2017-04-201-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We made some effort to reduce the RTNL lock scope when resetting and rebuilding the PF. Unfortunately we still held the RTNL lock during the VF reset operation, which meant that multiple PFs could not reset in parallel due to the global lock. For now, further reduce the scope by not holding the RTNL lock while resetting VFs. This allows multiple PFs to reset in a timely manner. Change-ID: I2fbf823a0063f24dff67676cad09f0bbf83ee4ce Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: new AQ commandsJingjing Wu2017-04-208-0/+686
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add admin queue functions for Pipeline Personalization Profile AQ commands: - Write Recipe Command buffer (Opcode: 0x0270) - Get Applied Profiles list (Opcode: 0x0271) Change-ID: I558b4145364140f624013af48d4bbf79d21ebb0d Signed-off-by: Jingjing Wu <jingjing.wu@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e/i40evf: Add tracepointsScott Peterson2017-04-208-0/+495
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds tracepoints to the i40e and i40evf drivers to which BPF programs can be attached for feature testing and verification. It's expected that an attached BPF program will identify and count or log some interesting subset of traffic. The bcc-tools package is helpful there for containing all the BPF arcana in a handy Python wrapper. Though you can make these tracepoints log trace messages, the messages themselves probably won't be very useful (other to verify the tracepoint is being called while you're debugging your BPF program). The idea here is that tracepoints have such low performance cost when disabled that we can leave these in the upstream drivers. This may eventually enable the instrumentation of unmodified customer systems should the need arise to verify a NIC feature is working as expected. In general this enables one set of feature verification tools to be used on these drivers whether they're built with the kernel or separately. Users are advised against using these tracepoints for anything other than a diagnostic tool. They have a performance impact when enabled, and their exact placement and form may change as we see how well they work in practice for the purposes above. Change-ID: Id6014a7322c0e6d08068114dd20bd156f2f6435e Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: dump VF information in debugfsMitch Williams2017-04-201-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dump some internal state about VFs through debugfs. This provides information not available with 'ip link show'. To use, write "dump vf <id>" to the command file, or just "dump vf" to dump information on all of the VFs. Change-ID: Ibe32b7f4ae55d4358c0b903217475f708ada1ecd Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e: Fix support for flow director programming statusAlexander Duyck2017-04-203-31/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an issue I introduced when I converted the code over to using the length field to determine if a descriptor was done or not. It turns out that we are also processing programming descriptors in the Rx path and need to have these processed even though the length field will be 0 on these packets. What will happen with a programming descriptor is that we will receive a descriptor that has the SPH bit set, and the header length and packet length fields cleared. To account for this we should be checking for the bit for split header being set even though we aren't actually using header split. This bit is set in the length field to indicate if a programming descriptor response is contained in the descriptor. Since we don't support header split we don't need to perform the extra checks of using a fixed value for the entire length field. In addition I am moving the function for checking if a filter is a programming status filter into the i40e_txrx.c file since there is no longer support for FCoE it doesn't make sense to keep this file in i40e.h. Change-ID: I12c359c3dc70adb9d6b92b27324bb2c7f04c1a06 Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40e/i40evf: Remove VF Rx csum offload for tunneled packetsalice michael2017-04-201-7/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rx checksum offload for tunneled packets was never being negotiated or requested by VF. This capability was assumed by default and enabled in current hardware for VF. Going forward, this feature needs to be disabled or advanced ptypes should be negotiated with PF in the future. Change-ID: I9e54cfa8a90e03ab6956db4412f1e337ccd2c2e0 Signed-off-by: Preethi Banala <preethi.banala@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
| * | i40evf: Use net_device_stats from struct net_deviceTobias Klauser2017-04-203-28/+11Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a private copy of struct net_device_stats in struct i40evf_adapter, use stats from struct net_device. Also remove the now unnecessary .ndo_get_stats function. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: Fix output from ixgbe_dumpAlexander Duyck2017-04-191-3/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I just found that when we had changed the Rx path to check for length instead of the DD bit we introduced an issue in ixgbe_dump since we were no longer clearing the status bits. To correct this I am updating ixgbe_dump to look for the length bits in the descriptor since that is what we are using in the Rx path. Fixes: c3630cc40b4f ("ixgbe: Use length to determine if descriptor is done") Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: Add support for maximum headroom when using build_skbAlexander Duyck2017-04-182-8/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch increases the headroom allocated when using build_skb on a system with 4K pages. Specifically the breakdown of headroom versus cache size is as follows: L1 Cache Size Headroom 64 192 64, NET_IP_ALIGN == 2 194 128 128 128, NET_IP_ALIGN == 2 130 256 512 256, NET_IP_ALIGN == 2 258 I stopped at supporting only a cache line size of 256 as that was the largest cache size I could find supported in the kernel. With this we are guaranteeing at least 128 bytes of headroom to spare in the frame. This should be enough for us to insert a couple of IPv6 headers if needed which is likely enough room for anything XDP should need. I'm leaving the padding for systems with pages larger than 4K unmodified for now. XDP currently isn't really setup to work on those types of systems so we can cross that bridge when we get there. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: add check for VETO bit when configuring link for KRTony Nguyen2017-04-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We did not have a check in place for MMNGC.MNG_VETO when setting up link on X550EM_X KR devices which resulted in link loss for the BMC when loading the driver. This patch adds a check for ixgbe_check_reset_blocked() in setup_link() since in that case there is no PHY reset function. Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbevf: use new api ethtool_{get|set}_link_ksettingsPhilippe Reynes2017-04-181-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes <tremyfr@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: Remove unused defineDon Skidmore2017-04-181-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the Marvell 1145 PHY define as we have never had a device that supports it and have no plan to in the future. The existence of this define has caused confusing on whether or not this PHY was supported by ixgbe. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: do not use adapter->num_vfs when setting VFs via module parameterEmil Tantilov2017-04-183-30/+28Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid setting adapter->num_vfs early in the init code path when using the max_vfs module parameter by passing it to ixgbe_enable_sriov() as a function parameter. This fixes an issue where if we failed to allocate vfinfo in __ixgbe_enable_sriov() the driver will crash with NULL pointer in ixgbe_disable_sriov() when attempting to free the vfinfo struct based on adapter->num_vfs. Also it cleans up the assignment of adapter->num_vfs since now it will only be set in __ixgbe_enable_sriov() and cleared in ixgbe_disable_sriov(). Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: return early instead of wrap block in if statementEmil Tantilov2017-04-181-44/+41Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we exit at the end of the block, we can save a level of indentation by performing an early return, and make the next several sections of code more legible, with fewer 80 character line breaks. Also moved allocating vfinfo at the beginning and the notification for enabling SRIOV at the end of the function when we know that it will succeed. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
* | | ixgbe: move num_vfs_macvlans allocation into separate functionEmil Tantilov2017-04-181-19/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Move the code allocating memory for list of MAC addresses that the VFs can use for MACVLAN into its own function. Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-16 10:00:58 +0200