aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/intel/i40e/i40e_main.c (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-03-26i40e: add support for XDP_REDIRECTBjörn Töpel1-0/+2
The driver now acts upon the XDP_REDIRECT return action. Two new ndos are implemented, ndo_xdp_xmit and ndo_xdp_flush. XDP_REDIRECT action enables XDP program to redirect frames to other netdevs. Signed-off-by: Björn Töpel <bjorn.topel@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-26i40e: hold the RTNL lock while changing interrupt schemesJacob Keller1-2/+17
When we suspend and resume, we need to clear and re-enable the interrupt scheme. This was previously not done while holding the RTNL lock, which could be problematic, because we are actually destroying and re-creating queues. Hold the RTNL lock for the entire sequence of preparing for reset, and when resuming. This additionally protects the flags related to interrupt scheme under RTNL lock so that their modification is properly threaded. This is part of a larger effort to remove the need for cmpxchg64 in i40e_set_priv_flags(). 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>
2018-03-26i40e: move client flags into state bitsJacob Keller1-12/+10
The iWarp client flags are all potentially changed when the RTNL lock is not held, so they should not be part of the pf->flags variable. Instead, move them into the state field so that we can use atomic bit operations. This is part of a larger effort to remove cmpxchg64 in i40e_set_priv_flags() 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>
2018-03-26i40e: move I40E_FLAG_TEMP_LINK_POLLING to state fieldJacob Keller1-4/+3
This flag is modified outside of the RTNL lock and thus should not be part of the pf->flags variable. Use a state bit instead, so that we can use atomic bit operations. This is part of a larger effort to remove cmpxchg64 in i40e_set_priv_flags() 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>
2018-03-26i40e: move AUTO_DISABLED flags into the state fieldJacob Keller1-14/+9
The two Flow Directory auto disable flags are used at run time to mark when the flow director features needed to be disabled. Thus the flags could change even when the RTNL lock is not held. They also have some code constructions which really should be test_and_set or test_and_clear using atomic bit operations. Create new state fields to mark this, and stop including them in pf->flags. This is part of a larger effort to remove the need for cmpxchg64 in i40e_set_priv_flags(). 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>
2018-03-26i40e: move I40E_FLAG_UDP_FILTER_SYNC to the state fieldJacob Keller1-6/+4
This flag is modified during run time, possibly even when the RTNL lock is not held. Additionally it has a few places which should be using test_and_set or test_and_clear atomic bit operations. Create a new state bit __I40E_UDP_SYNC_PENDING and use it instead of the ole I40E_FLAG_UDP_FILTER_SYNC flag. This is part of a larger effort to remove the need for using cmpxchg64 in i40e_set_priv_flags. 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>
2018-03-26i40e: move I40E_FLAG_FILTER_SYNC to a state bitJacob Keller1-7/+9
The I40E_FLAG_FILTER_SYNC flag is modified during run time possibly when the RTNL lock is not held. Thus, it should not be part of pf->flags, and instead should be using atomic bit operations in the pf->state field. Create a __I40E_MACVLAN_SYNC_PENDING state bit, and use it instead of the old I40E_FLAG_FILTER_SYNC flag. This is part of a larger effort to remove the need for cmpxchg64 in i40e_set_priv_flags(). 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>
2018-03-23intel: add SPDX identifiers to all the Intel driversJeff Kirsher1-0/+1
Add the SPDX identifiers to all the Intel wired LAN driver files, as outlined in Documentation/process/license-rules.rst. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-19i40e: Close client on suspend and restore client MSIx on resumeShiraz Saleem1-0/+8
During suspend client MSIx vectors are freed while they are still in use causing a crash on entering S3. Fix this calling client close before freeing up its MSIx vectors. Also update the client MSIx vectors on resume before client open is called. Fixes commit b980c0634fe5 ("i40e: shutdown all IRQs and disable MSI-X when suspended") Reported-by: Stefan Assmann <sassmann@redhat.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-14i40e: restore TCPv4 input set when re-enabling ATRJacob Keller1-0/+9
When we re-enable ATR we need to restore the input set for TCPv4 filters, in order for ATR to function correctly. We already do this for the normal case of re-enabling ATR when disabling ntuple support. However, when re-enabling ATR after the last TCPv4 filter is removed (but when ntuple support is still active), we did not restore the TCPv4 filter input set. This can cause problems if the TCPv4 filters from FDir had changed the input set, as ATR will no longer behave as expected. When clearing the ATR auto-disable flag, make sure we restore the TCPv4 input set to avoid this. 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>
2018-03-14i40e: factor out re-enable functions for ATR and SBJacob Keller1-16/+32
A future patch needs to expand on the logic for re-enabling ATR. Doing so would cause some code to break the 80-character line limit. To reduce the level of indentation, factor out helper functions for re-enabling ATR and SB rules. 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>
2018-03-14i40e: track filter type statistics when deleting invalid filtersJacob Keller1-8/+48
When hardware has trouble with a particular filter, we delete it from the list. Unfortunately, we did not properly update the per-filter statistic when doing so. Create a helper function to handle this, and properly reduce the necessary counter so that it tracks the number of active filters properly. 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>
2018-03-14i40e: Cleanup i40e_vlan_rx_registerJacob Keller1-17/+4
We used to use the function i40e_vlan_rx_register as a way to hook into the now defunct .ndo_vlan_rx_register netdev hook. This was removed but we kept the function around because we still used it internally to control enabling or disabling of VLAN stripping. As pointed out in upstream review, VLAN stripping is only used in a single location and the previous function is quite small, just inline it into i40e_restore_vlan() rather than carrying the function separately. 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>
2018-02-26i40e: link_down_on_close private flag supportMariusz Stachura1-0/+75
This patch introduces new ethtool private flag used for forcing true link state. Function i40e_force_link_state that implements this functionality was added, it sets phy_type = 0 in order to work-around firmware's LESM. False positive error messages were suppressed. The ndo_open() should not succeed if there were issues with forcing link state to be UP. Added I40E_PHY_TYPES_BITMASK define with all phy types OR-ed together in one bitmask. Added after phy type definition, so it will be hard to forget to include new phy types to the bitmask. Signed-off-by: Mariusz Stachura <mariusz.stachura@intel.com> 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>
2018-02-14i40e: Add and delete cloud filterAvinash Dayanand1-11/+5
This patch provides support to add or delete cloud filter for queue channels created for ADq on VF. We are using the HW's cloud filter feature and programming it to act as a TC filter applied to a group of queues. There are two possible modes for a VF when applying a cloud filter 1. Basic Mode: Intended to apply filters that don't need a VF to be Trusted. This would include the following Dest MAC + L4 port Dest MAC + VLAN + L4 port 2. Advanced Mode: This mode is only for filters with combination that requires VF to be Trusted. Dest IP + L4 port When cloud filters are applied on a trusted VF and for some reason the same VF is later made as untrusted then all cloud filters will be deleted. All cloud filters has to be re-applied in such a case. Cloud filters are also deleted when queue channel is deleted. Testing-Hints: ============= 1. Adding Basic Mode filter should be possible on a VF in Non-Trusted mode. 2. In Advanced mode all filters should be able to be created. Steps: ====== 1. Enable ADq and create TCs using TC mqprio command 2. Apply cloud filter. 3. Turn-off the spoof check. 4. Pass traffic. Example: ======== 1. tc qdisc add dev enp4s2 root mqprio num_tc 4 map 0 0 0 0 1 2 2 3\ queues 2@0 2@2 1@4 1@5 hw 1 mode channel 2. tc qdisc add dev enp4s2 ingress 3. ethtool -K enp4s2 hw-tc-offload on 4. ip link set ens261f0 vf 0 spoofchk off 5. tc filter add dev enp4s2 protocol ip parent ffff: prio 1 flower\ dst_ip 192.168.3.5/32 ip_proto udp dst_port 25 skip_sw hw_tc 2 Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: i40e: Change ethtool check from MAC to HW flagDave Ertman1-0/+10
The MAC, FW Version and NPAR check used to determine if shutting off the FW LLDP engine is supported is not using the usual feature check mechanism. This patch fixes the problem by moving the feature check to i40e_sw_init in order to set a flag in pf->hw_features that ethtool will use for priv_flags disable operation. Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: do not force filter failure in overflow promiscuousAlan Brady1-14/+1
Broadcast filters can now cause overflow promiscuous to trigger when adding "too many" VLANs to all the ports of a device and the driver needs a way to exit overflow promiscuous once triggered. Currently the driver looks to see if there are "too many" filters and/or we have any failed filters to determine when it is safe to exit overflow promiscuous. If we trigger overflow promiscuous with broadcast filters, any new filters added will be "auto-failed" until we exit overflow promiscuous. Since the user can't manually remove the failed broadcast filters for VLANs (nor should we expect the user to do such), there is no way to exit overflow promiscuous without reloading the driver. The easiest way to do this is to remove the shortcut to "auto-fail" filters in overflow promiscuous. If the user removes the VLANs, the failed filters will be removed and since we're no longer "auto-failing" new filters, we'll eventually get a good set of filters and exit overflow promiscuous. This has the side benefit of making filter state more explicit in that if a filter says it's failed we know for a fact it failed and not just assuming it will if we're in overflow promiscuous. This is nice because if the user removes some filters and then adds some, even if we're in overflow promiscuous, the filter might succeed; we were just assuming it won't because the user hasn't rectified other existing failed filters. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: refactor promisc_changed in i40e_sync_vsi_filtersAlan Brady1-22/+20
This code here is quite complex and easy to screw up. Let's see if we can't improve the readability and maintainability a bit. This refactors out promisc_changed into two variables 'old_overflow' and 'new_overflow' which makes it a bit clearer when we're concerned about when and how overflow promiscuous is changed. This also makes so that we no longer need to pass a boolean pointer to i40e_aqc_add_filters. Instead we can simply check if we changed the overflow promiscuous flag since the function start. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: broadcast filters can trigger overflow promiscuousAlan Brady1-2/+4
When adding a bunch of VLANs to all the ports on a device, it's possible to run out of space for broadcast filters. The driver should trigger overflow promiscuous in this circumstance to prevent traffic from being unexpectedly dropped. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-13i40e: don't leak memory addressesMitch Williams1-7/+6
Could a Bad Person do Bad Things to a server if they found these addresses printed in the log? Who knows? But let's not take that risk. Remove pointers from a bunch of printks. In some cases, I was able to adjust the message to indicate whether or not the value was null. In others, I just removed the entire message as there was really no hope of saving it. 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>
2018-02-13i40e: Make local function i40e_get_link_speed staticWei Yongjun1-1/+1
Fixes the following sparse warning: drivers/net/ethernet/intel/i40e/i40e_main.c:5440:5: warning: symbol 'i40e_get_link_speed' was not declared. Should it be static? Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-12i40e/i40evf: Add support for new mechanism of updating adaptive ITRAlexander Duyck1-9/+6
This patch replaces the existing mechanism for determining the correct value to program for adaptive ITR with yet another new and more complicated approach. The basic idea from a 30K foot view is that this new approach will push the Rx interrupt moderation up so that by default it starts in low latency and is gradually pushed up into a higher latency setup as long as doing so increases the number of packets processed, if the number of packets drops to 4 to 1 per packet we will reset and just base our ITR on the size of the packets being received. For Tx we leave it floating at a high interrupt delay and do not pull it down unless we start processing more than 112 packets per interrupt. If we start exceeding that we will cut our interrupt rates in half until we are back below 112. The side effect of these patches are that we will be processing more packets per interrupt. This is both a good and a bad thing as it means we will not be blocking processing in the case of things like pktgen and XDP, but we will also be consuming a bit more CPU in the cases of things such as network throughput tests using netperf. One delta from this versus the ixgbe version of the changes is that I have made the interrupt moderation a bit more aggressive when we are in bulk mode by moving our "goldilocks zone" up from 48 to 96 to 56 to 112. The main motivation behind moving this is to address the fact that we need to update less frequently, and have more fine grained control due to the separate Tx and Rx ITR times. 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>
2018-02-12i40e/i40evf: Split container ITR into current_itr and target_itrAlexander Duyck1-8/+14
This patch is mostly prep-work for replacing the current approach to programming the dynamic aka adaptive ITR. Specifically here what we are doing is splitting the Tx and Rx ITR each into two separate values. The first value current_itr represents the current value of the register. The second value target_itr represents the desired value of the register. The general plan by doing this is to allow for deferring the update of the ITR value under certain circumstances. For now we will work with what we have, but in the future I hope to change the behavior so that we always only update one ITR at a time using some simple logic to determine which ITR requires an update. 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>
2018-02-12i40e: Add delay after EMP reset for firmware to recoverFilip Sadowski1-0/+11
This patch adds necessary delay for 4.33 firmware to recover after EMP reset. Without this patch driver occasionally reinitializes structures too quickly to communicate with firmware after EMP reset causing AdminQ to timeout. Signed-off-by: Filip Sadowski <filip.sadowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-02-12i40e/i40evf: Only track one ITR setting per ring instead of Tx/RxAlexander Duyck1-7/+7
The rings are already split out into Tx and Rx rings so it doesn't make sense to have any single ring store both a Tx and Rx itr_setting value. Since that is the case drop the pair in favor of storing just a single ITR value. 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>
2018-02-07i40e: Fix the number of queues available to be mapped for useAmritha Nambiar1-13/+14
Fix the number of queues per enabled TC and report available queues to the kernel without having to limit them to the max RSS limit so they are available to be mapped for XPS. This allows a queue per processing thread available for handling traffic for the given traffic class. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-26i40e: Do not allow use more TC queue pairs than MSI-X vectors existPaweł Jabłoński1-0/+4
This patch suppresses the message about invalid TC mapping and wrong selected TX queue. The root cause of this bug was setting too many TC queue pairs on huge multiprocessor machines. When quantity of the TC queue pairs is exceeding MSI-X vectors count then TX queue number can be selected beyond actual TX queues amount. Signed-off-by: Paweł Jabłoński <pawel.jablonski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-26i40e/i40evf: Record ITR register location in the q_vectorAlexander Duyck1-0/+1
The drivers for i40e and i40evf had a reg_idx value stored in the q_vector that was going completely unused. I can only assume this was copied over from ixgbe and nobody knew how to use it. I'm going to make use of the value to avoid having to compute the vector and thus the register index for multiple paths throughout the drivers. 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>
2018-01-26i40e: program fragmented IPv4 filter input setJacob Keller1-0/+3
When implementing support for IP_USER_FLOW filters, we correctly programmed a filter for both the non fragmented IPv4/Other filter, as well as the fragmented IPv4 filters. However, we did not properly program the input set for fragmented IPv4 PCTYPE. This meant that the filters would almost certainly not match, unless the user specified all of the flow types. Add support to program the fragmented IPv4 filter input set. Since we always program these filters together, we'll assume that the two input sets must match, and will thus always program the input sets to the same value. 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>
2018-01-26i40e: Fix kdump failureAvinash Dayanand1-2/+2
kdump fails in the system when used in conjunction with Ethernet driver X722/X710. This is mainly because when we are resource constrained i.e. when we have just one online_cpus, we are enabling VMDq and iWARP. It doesn't make sense to enable them with just one CPU and starve kdump for lack of IRQs. So don't enable VMDq or iWARP when we just have a single CPU. Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-26i40e: fix FW_LLDP flag on initAlan Brady1-0/+3
Using ethtool --set-priv-flags disable-fw-lldp <on/off> is persistent across reboots/reloads so we need some mechanism in the driver to detect if it's on or off on init so we can set the ethtool private flag appropriately. Without this, every time the driver is reloaded the flag will default to off regardless of whether it's on or off in FW. We detect this by first attempting to program DCB and if AQ fails returning I40E_AQ_RC_EPERM, we know that LLDP is disabled in FW. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-26i40e: Implement an ethtool private flag to stop LLDP in FWDave Ertman1-2/+12
Implement the private flag disable-fw-lldp for ethtool to disable the processing of LLDP packets by the FW. This will stop the FW from consuming LLDPDU and cause them to be sent up the stack. The FW is also being configured to apply a default DCB configuration on link up. Toggling the value of this flag will also cause a PF reset. Disabling FW DCB will also disable DCBx. Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-25i40e: use tc_cls_can_offload_and_chain0()Jakub Kicinski1-5/+3
Make use of tc_cls_can_offload_and_chain0() to set extack msg in case ethtool tc offload flag is not set or chain unsupported. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-24i40e: flower: check if TC offload is enabled on a netdevJakub Kicinski1-0/+2
Since TC block changes drivers are required to check if the TC hw offload flag is set on the interface themselves. Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower") Fixes: 44ae12a768b7 ("net: sched: move the can_offload check from binding phase to rule insertion phase") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Amritha Nambiar <amritha.nambiar@intel.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-01-23i40e: Fix channel addition in reset flowAmritha Nambiar1-0/+11
Fix recreating the channel VSIs during the reset flow to reconfigure the Tx rings and the queue context associated with the channel VSI. Also update the next_base_queue for the VSI while rebuilding the channel VSIs after a reset. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-23i40e: Delete an error message for a failed memory allocation in i40e_init_interrupt_scheme()Markus Elfring1-3/+2
Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-23i40e: simplify pointer dereferencesMitch Williams1-10/+8
Now that i40e_vsi_config_tc() has the pf and hw variable defined, use them, instead of dereferencing vsi->back. Much easier to read. 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>
2018-01-23i40e: check for invalid DCB configMitch Williams1-1/+33
The driver (and the entire netdev layer for that matter) assumes that TC0 will always be present in our DCB configuration. Unfortunately, this isn't always the case. Rather than fail to configure the VSI, let's go ahead and try to make it work, even though DCB will end up being disabled by the kernel. If the driver fails to configure DCB, the driver queries what's valid, then writes that back to the hardware, always forcing TC0. This fixes a bug where the driver could fail to adhere to ETS BW allocations if 8 TCs were configured on the switch. 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>
2018-01-23i40e/i40evf: Detect and recover hung queue scenarioSudheer Mogilappagari1-99/+1
In VFs, there is a known issue which can cause writebacks to not occur when interrupts are disabled and there are less than 4 descriptors resulting in TX timeout. Timeout can also occur due to lost interrupt. The current implementation for detecting and recovering from hung queues in the PF is problematic because it actually actively encourages lost interrupts. By triggering a SW interrupt, interrupts are forced on. If we are already in napi_poll and an interrupt fires, napi_poll will not be rescheduled and the interrupt is effectively lost; thereby potentially *causing* hung queues. This patch checks whether packets are being processed between every watchdog cycle and determine potential hung queue and fires triggers SW interrupt only for that particular queue. Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-23i40e: avoid divide by zeroMitch Williams1-2/+7
In some weird circumstances with DCB enabled, the firmware can fail to configure the VSI, leaving us with zero traffic classes. Check for this state when we configure RSS to avoid a panic. 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>
2018-01-23i40e/i40evf: Enable NVMUpdate to retrieve AdminQ and add preservation flags for NVM updatePawel Jablonski1-1/+1
This patch adds new I40E_NVMUPD_GET_AQ_EVENT state to allow retrieval of AdminQ events as a result of AdminQ commands sent to firmware. Add preservation flags support on X722 devices for NVM update AdminQ function wrapper. Add new parameter and handling to nvmupdate admin queue function intended to allow nvmupdate tool to configure the preservation flags in the AdminQ command. This is required to implement FlatNVM on X722 devices. Signed-off-by: Pawel Jablonski <pawel.jablonski@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-10i40e/i40evf: Bump driver versionsAlice Michael1-2/+2
Bump the i40e driver from 2.1.14 to 2.3.2. Bump the i40evf driver from 3.0.1 to 3.2.2 Signed-off-by: Alice Michael <alice.michael@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-03i40e: flower: Fix return value for unsupported offloadJiri Pirko1-1/+1
When filter configuration is not supported, drivers should return -EOPNOTSUPP so the core can react correctly. Fixes: 2f4b411a3d67 ("i40e: Enable cloud filters via tc-flower") Signed-off-by: Jiri Pirko <jiri@mellanox.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-01-03i40e: don't remove netdev->dev_addr when syncing uc listJacob Keller1-1/+16
In some circumstances, such as with bridging, it is possible that the stack will add a devices own MAC address to its unicast address list. If, later, the stack deletes this address, then the i40e driver will receive a request to remove this address. The driver stores its current MAC address as part of the MAC/VLAN hash array, since it is convenient and matches exactly how the hardware expects to be told which traffic to receive. This causes a problem, since for more devices, the MAC address is stored separately, and requests to delete a unicast address should not have the ability to remove the filter for the MAC address. Fix this by forcing a check on every address sync to ensure we do not remove the device address. There is a very narrow possibility of a race between .set_mac and .set_rx_mode, if we don't change netdev->dev_addr before updating our internal MAC list in .set_mac. This might be possible if .set_rx_mode is going to remove MAC "XYZ" from the list, at the same time as .set_mac changes our dev_addr to MAC "XYZ", we might possibly queue a delete, then an add in .set_mac, then queue a delete in .set_rx_mode's dev_uc_sync and then update netdev->dev_addr. We can avoid this by moving the copy into dev_addr prior to the changes to the MAC filter list. A similar race on the other side does not cause problems, as if we're changing our MAC form A to B, and we race with .set_rx_mode, it could queue a delete from A, we'd update our address, and allow the delete. This seems like a race, but in reality we're about to queue a delete of A anyways, so it would not cause any issues. A race in the initialization code is unlikely because the netdevice has not yet been fully initialized and the stack should not be adding or removing addresses yet. Note that we don't (yet) need similar code for the VF driver because it does not make use of __dev_uc_sync and __dev_mc_sync, but instead roles its own method for handling updates to the MAC/VLAN list, which already has code to protect against removal of the hardware address. 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>
2018-01-03i40e: Remove UDP support for big bufferAmritha Nambiar1-9/+9
Since UDP based filters are not supported via big buffer cloud filters, remove UDP support. Also change a few return types to indicate unsupported vs invalid configuration. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Acked-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>
2017-11-27i40e: Fix reporting incorrect error codesAmritha Nambiar1-1/+0
Adding cloud filters could fail for a number of reasons, unsupported filter fields for example, which fails during validation of fields itself. This will not result in admin command errors and converting the admin queue status to posix error code using i40e_aq_rc_to_posix would result in incorrect error values. If the failure was due to AQ error itself, reporting that correctly is handled in the inner function. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-11-21i40e: Use smp_rmb rather than read_barrier_dependsBrian King1-1/+1
The original issue being fixed in this patch was seen with the ixgbe driver, but the same issue exists with i40e as well, as the code is very similar. read_barrier_depends is not sufficient to ensure loads following it are not speculatively loaded out of order by the CPU, which can result in stale data being loaded, causing potential system crashes. Cc: stable <stable@vger.kernel.org> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-11-21i40e: restore promiscuous after resetAlan Brady1-72/+83
After a reset we rebuild the VSIs which is going to clobber any promiscuous settings we had before reset. This makes it so that we restore the promiscuous settings we had before reset. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-11-21i40e: Remove limit of 64 max queues per channelAmritha Nambiar1-8/+0
It is safe to remove the upper limit of 64 queues on a channel VSI. The upper bound is determined by the VSI's num_queue_pairs and gets validated when the queue mapping info through mqprio interface is subject to bound checking in the driver. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-11-08net_sch: mqprio: Change TC_SETUP_MQPRIO to TC_SETUP_QDISC_MQPRIONogah Frankel1-1/+1
Change TC_SETUP_MQPRIO to TC_SETUP_QDISC_MQPRIO to match the new convention. Signed-off-by: Nogah Frankel <nogahf@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>