summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet/intel/i40e/i40e_main.c
AgeCommit message (Collapse)Author
2017-04-30i40e: remove hw_disabled_flags in favor of using separate flag bitsJacob Keller
The hw_disabled_flags field was added as a way of signifying that a feature was automatically or temporarily disabled. However, we actually only use this for FDir features. Replace its use with new _AUTO_DISABLED flags instead. This is more readable, because you aren't setting an *_ENABLED flag to *disable* the feature. Additionally, clean up a few areas where we used these bits. First, we don't really need to set the auto-disable flag for ATR if we're fully disabling the feature via ethtool. Second, we should always clear the auto-disable bits in case they somehow got set when the feature was disabled. However, avoid displaying a message that we've re-enabled the feature. Third, we shouldn't be re-enabling ATR in the SB ntuple add flow, because it might have been disabled due to space constraints. Instead, we should just wait for the fdir_check_and_reenable to be called by the watchdog. Overall, this change allows us to simplify some code by removing an extra field we didn't need, and the result should make it more clear as to what we're actually doing with these 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>
2017-04-30i40e: use DECLARE_BITMAP for state fieldsJacob Keller
Instead of assuming our flags fit within an unsigned long, use DECLARE_BITMAP which will ensure that we always allocate enough space. Additionally, use __I40E_STATE_SIZE__ markers as the last element of the enumeration so that the size of the BITMAP is compile-time assigned rather than programmer-time assigned. This ensures that potential future flag additions do not actually overrun the array. This is especially important as 32bit systems would only have 32bit longs instead of 64bit longs as we generally have assumed in the prior code. This change also removes a dereference of the state fields throughout the code, so it does have a bit of code churn. The conversions were automated using sed replacements with an alternation s/&(vsi->back|vsi|pf)->state/\1->state/ s/&adapter->vsi.state/adapter->vsi.state/ For debugfs, we modify the printing so that we can display chunks of the state value on new lines. This ensures that we can print the entire set of state values. Additionally, we now print them as 08lx to ensure that they display nicely. 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>
2017-04-30i40e: separate PF and VSI state flagsJacob Keller
Avoid using the same named flags for both vsi->state and pf->state. This makes code review easier, as it is more likely that future authors will use the correct state field when checking bits. Previous commits already found issues with at least one check, and possibly others may be incorrect. This reduces confusion as it is more clear what each flag represents, and which flags are valid for which state field. 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>
2017-04-30i40e: remove unnecessary msleep() delay in i40e_free_vfsJacob Keller
The delay was added because of a desire to ensure that the VF driver can finish up removing. However, pci_disable_sriov already has its own ssleep() call that will sleep for an entire second, so there is no reason to add extra delay on top of this by using msleep here. In practice, an msleep() won't have a huge impact on timing but there is no real value in keeping it, so lets just simplify the code and remove it. 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>
2017-04-30i40e: Reprogram port offloads after resetAlexander Duyck
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>
2017-04-30i40e: rename index to port to avoid confusionJacob Keller
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>
2017-04-30i40e: properly spell I40E_VF_STATE_* flagsJacob Keller
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>
2017-04-19i40e: use i40e_stop_rings_no_wait to implement PORT_SUSPENDED stateJacob Keller
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>
2017-04-19i40e: reset all VFs in parallel when rebuilding PFJacob Keller
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>
2017-04-19i40e: factor out queue control from i40e_vsi_control_(tx|rx)Jacob Keller
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>
2017-04-19i40e: don't hold RTNL lock while waiting for VF reset to finishJacob Keller
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>
2017-04-19i40e/i40evf: Add tracepointsScott Peterson
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>
2017-04-08i40e/i40evf: Add support for padding start of framesAlexander Duyck
This patch adds padding to the start of frames to make room for headroom for us to eventually start using build_skb. Right now we guarantee at least NET_SKB_PAD + NET_IP_ALIGN, however we allocate more space if more is available. For example on x86 the headroom should be 192 bytes. On systems that have too large of a cache line size to support storing 1.5K padding and shared info we default to using 3K buffers and reserve everything that isn't used for skb_shared_info or the data buffer for headroom. Change-ID: I33c641c9a1ea10cf7cc484c2d20985368d2d709a 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>
2017-04-08i40e/i40evf: Add support for using order 1 pages with a 3K bufferAlexander Duyck
There are situations where adding padding to the front and back of an Rx buffer will require that we add additional padding. Specifically if NET_IP_ALIGN is non-zero, or the MTU size is larger than 7.5K we would need to use 2K buffers which leaves us with no room for the padding. To preemptively address these cases I am adding support for 3K buffers to the Rx path so that we can provide the additional padding needed in the event of NET_IP_ALIGN being non-zero or a cache line being greater than 64. Change-ID: I938bc1ba611285428df39a613cd66f98e60b55c7 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>
2017-04-08i40e: remove I40E_FLAG_NEED_LINK_UPDATEAlice Michael
The I40E_FLAG_NEED_LINK_UPDATE was never used. Remove the flag definitions. Change-ID: If59d0c6b4af85ca27281f3183c54b055adb439a4 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>
2017-04-08i40e: remove extraneous loop in i40e_vsi_wait_queues_disabledJacob Keller
We can simply check both Tx and Rx queues in a single loop, rather than repeating the loop twice. Change-ID: Ic06f26b0e3c2620e0e33c1a2999edda488e647ad 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>
2017-04-08i40e: allow look-up of MAC address from Open Firmware or IDPROMJacob Keller
Look up the MAC address from the eth_get_platform_mac_address() function first before checking what the firmware provides. We already handle the case of re-writing the MAC-VLAN filter, so there is no need to add extra code for this. However, update the comment where we do this to indicate that it does impact the Open Firmware MAC address case. Change-ID: I73e59fbe0b0e7e6f3ee9f5170d0bd3a4d5faf4db 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>
2017-04-08i40e: Simplify i40e_detect_recover_hung_queue logicAlan Brady
This patch greatly reduces the unneeded complexity in the i40e_detect_recover_hung_queue code path. The previous implementation set a 'hung bit' which would then get cleared while polling. If the detection routine was called a second time with the bit already set, we would issue a software interrupt. This patch makes it such that if interrupts are disabled and we have pending TX descriptors, we trigger a software interrupt since in, the worst case, queues are already clean and we have an extra interrupt. Additionally this patch removes the workaround for lost interrupts as calling napi_reschedule in this context can cause software interrupts to fire on the wrong CPU. Change-ID: Iae108582a3ceb6229ed1d22e4ed6e69cf97aad8d 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-04-08i40e: Decrease the scope of rtnl lockMaciej Sosin
Previously rtnl lock was held during whole reset procedure that was stopping other PFs running their reset procedures. In the result reset was not handled properly and host reset was the only way to recover. Change-ID: I23c0771c0303caaa7bd64badbf0c667e25142954 Signed-off-by: Maciej Sosin <maciej.sosin@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-04-08i40e: only register client on iWarp-capable devicesMitch Williams
The client interface is only intended for use on devices that support iWarp. Only register with the client if this is the case. This fixes a panic when loading i40iw on X710 devices. Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Reported-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-04-06i40e: close client on remove and shutdownMitch Williams
When the driver is removed or shut down, close any attached clients (i.e. i40iw). This prevents a panic seen sometimes on forced driver removal or system shutdown when iWarp is running. Change-ID: I4f6161e5a73ffbb2fd5883567b007310302bfcb5 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>
2017-04-06i40e/i40evf: Add capability exchange for outer checksumPreethi Banala
This patch adds a capability negotiation between VF and PF using ENCAP/ ENCAP_CSUM offload flags in order for the VF to support outer checksum and TSO offloads for encapsulated packets. These capabilities were assumed by default and enabled in current hardware. Going forward, these features needs to be negotiated with PF before advertising to the stack. Additionally, strip out the mac.type checks for X722 since outer checksums are enabled based on the ENCAP_CSUM offload negotiation flag and maintain consistency between drivers in how the features are configured. Change-ID: Ie380a6f57eca557a2bb575b66b12fae36d308920 Signed-off-by: Preethi Banala <preethi.banala@intel.com> Signed-off-by: Alan Brady <alan.brady@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> 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>
2017-04-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Mostly simple cases of overlapping changes (adding code nearby, a function whose name changes, for example). Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-29i40e: fix for queue timing delaysWyborny, Carolyn
This patch adds a delay to Rx queue disables to accommodate HW needs. v2: Added missing check for disable only, additional details on the need for the ugly delay and fixed spacing on comment. Change-ID: I2864ca667ce5dcc2cc44f8718113b719742a46a1 Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-29i40e/i40evf: Change the way we limit the maximum frame size for RxAlexander Duyck
This patch changes the way we handle the maximum frame size for the Rx path. Previously we were rounding up to 2K for a 1500 MTU and then brining the max frame size down to MTU plus a fixed amount. With this patch applied what we now do is limit the maximum frame to 1.5K minus the value for NET_IP_ALIGN for standard MTU, and for any MTU greater than 1500 we allow up to the maximum frame size. This makes the behavior more consistent with the other drivers such as igb which had similar logic. In addition it reduces the test matrix for MTU since we only have two max frame sizes that are handled for Rx now. Change-ID: I23a9d3c857e7df04b0ef28c64df63e659c013f3f 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>
2017-03-29i40e: remove a useless goto statementJacob Keller
The goto found here for when in MFP mode is pointless. It jumps to the end of a series of if blocks. However, right after this statement is a closing '}' for this if block, which will result in the program flow going to the exact same location as the goto statement indicates. Thus, regardless of whether we are in MFP mode, the program flow will resume from the same location. This arose due to various refactoring which did not notice that this goto became essentially a no-op. To properly understand this diff you will need to view a larger context than is given by default. Change-ID: I088f73c3831aa5c4e2281380c7a3ce605594300c 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>
2017-03-29i40e: Check for new arq elements before leaving the adminq subtask loopChristopher N Bednarz
Fix a case where we miss an arq element if a new one is added before we enable interrupts and exit the arq subtask loop. This occurs frequently with RDMA running on Windows VF and causes long delays that prevent SMB from establishing connections. Change-ID: I3e1c8b2b960c12857d9b8275bea2c1563674392e Signed-off-by: Christopher N Bednarz <christopher.n.bednarz@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-27i40e: Drop FCoE code that always evaluates to false or 0Alexander Duyck
Since FCoE isn't supported by the i40e products there isn't much point in carrying around code that will always evaluate to false. This patch goes through and strips out the code in several spots so that we don't go around carrying variables and/or code that is always going to evaluate to false or 0. Change-ID: I39d1d779c66c638b75525839db2b6208fdc809d7 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>
2017-03-27i40e: Drop FCoE code from core driver filesAlexander Duyck
Looking over the code for FCoE it looks like the Rx path has been broken at least since the last major Rx refactor almost a year ago. It seems like FCoE isn't supported for any of the Fortville/Fortpark hardware so there isn't much point in carrying the code around, especially if it is broken and untested. Change-ID: I892de8fa551cb129ce2361e738ff82ce55fa229e 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>
2017-03-27i40e: removed no longer needed delaysBimmy Pujari
Removed no longer needed delays. At preproduction stage those delays were needed but now these delays are not needed. Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-27i40e: fix configuration of RSS table with DCBHarshitha Ramamurthy
There exists a bug in the driver where the calculation of the RSS size was not taking into account the number of traffic classes enabled. This patch factors in the traffic classes both in the initial configuration of the table as well as reconfiguration. Change-ID: I34dcd345ce52faf1d6b9614bea28d450cfd5f621 Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-24i40e: Do not enable NAPI on q_vectors that have no ringsAlexander Duyck
When testing the epoll w/ busy poll code I found that I could get into a state where the i40e driver had q_vectors w/ active NAPI that had no rings. This was resulting in a divide by zero error. To correct it I am updating the driver code so that we only support NAPI on q_vectors that have 1 or more rings allocated to them. 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> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-23i40e: make use of hlist_for_each_entry_continueJacob Keller
Replace a complex if->continue->else->break construction in i40e_next_filter. We can simply use hlist_for_each_entry_continue instead. This drops a lot of confusing code. The resulting code is much easier to understand the intention, and follows the more normal pattern for using hlist loops. We could have also used a break with a "return next" at the end of the function, instead of return NULL, but the current implementation is explicitly clear that when you reach the end of the loop you get a NULL value. The alternative construction is less clear since the reader would have to know that next is NULL at the end of the loop. Change-Id: Ife74ca451dd79d7f0d93c672bd42092d324d4a03 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>
2017-03-23i40e: add support for SCTPv4 FDir filtersJacob Keller
Enable FDir filters for SCTPv4 packets using the ethtool ntuple interface to enable filters. The ethtool API does not allow masking on the verification tag. Change-Id: I093e88a8143994c7e6f4b7b17a0bd5cf861d18e4 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>
2017-03-23i40e: implement support for flexible word payloadJacob Keller
Add support for flexible payloads passed via ethtool user-def field. This support is somewhat limited due to hardware design. The input set can only be programmed once per filter type, and the flexible offset is part of this filter input set. This means that the user cannot program both a regular and a flexible filter at the same time for a given flow type. Additionally, the user may not program two flexible filters of the same flow type with different offsets, although they are allowed to configure different values at that offset location. We support a single flexible word (2byte) value per protocol type, and we handle the FLX_PIT register using a list of flexible entries so that each flow type may be configured separately. Due to hardware implementation, the flexible data is offset from the start of the packet payload, and thus may not be in part of the header data. For this reason, the offset provided by the user defined data is interpreted as a byte offset from the start of the matching payload. Previous implementations have tried to represent the offset as from the start of the frame, but this is not feasible because header sizes may change due to options. Change-Id: 36ed27995e97de63f9aea5ade5778ff038d6f811 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>
2017-03-23i40e: restore default input set for each flow typeJacob Keller
Ensure that the default input set is correctly reprogrammed when cleaning up after disabling flow director support. This ensures that the programmed value will be in a clean state. Although we do not yet have support for SCTPv4 filters, a future patch will add support for this protocol, so we will correctly restore the SCTPv4 input set here as well. Note that strictly speaking the default hardware value for SCTP includes matching the verification tag. However, the ethtool API does not have support for specifying this value, so there is no reason to keep the verification field enabled. This patch is the next step on the way to enabling partial tuple filters which will be implemented in a following patch. Change-Id: Ic22e1c267ae37518bb036aca4a5694681449f283 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>
2017-03-20i40e: add counters for UDP/IPv4 and IPv4 filtersJacob Keller
In preparation for adding code to properly check the mask values, we will need to know the number of active filters for each type. Add counters for each filter type. Rename the already existing fd_tcp_rule to fd_tcp4_filter_cnt to match the style of other names. To avoid style warnings, avoid assigning multiple parameters at once, and fix up one other case where we did so previously. 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>
2017-03-20i40e: don't re-enable ATR when flushing filters if SB has TCP4/IPv4 rulesJacob Keller
When flushing and replaying FDIR filters, it is possible we would disable ATR, and then re-enable it even though we should have kept it disabled due to existing TCP/IPv4 filters. Fix this by checking whether we have TCP4/IPv4 filters before re-enabling. Alternatively, we could instead restore ATR and then replay filters, however, this would cause us to rapidly enable and then disable ATR in some cases. Change-ID: I076e4cc1e4409bce7f98f3c213295433a4ff43d8 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Avinash Dayanand <avinash.dayanand@intel.com> Reviewed-by: Alan Brady <alan.brady@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>
2017-03-20i40e: reset fd_tcp_rule count when restoring filtersJacob Keller
Since we're about to reprogram the filters, we need to ensure that the fd_tcp_rule count is correctly reset to 0. Otherwise, we will keep a stale count that does not accurately reflect the number of programmed TCPv4 filters. 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>
2017-03-20i40e: remove redundant check for fd_tcp_rule when restoring filtersJacob Keller
i40e_fdir_filter_restore re-adds all existing filters, which already checks when adding a TCPv4 filter to disable ATR. We don't need to make the check twice, so remove this redundant code. Change-ID: Ia0b0690e23523915199d601494557def135c9d7f 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>
2017-03-20i40e: send correct port number to AdminQ when enabling UDP tunnelsJacob Keller
The firmware expects the port numbers for offloaded UDP tunnels in Little Endian format. We accidentally sent the value in Big Endian format which obviously will cause the wrong port number to be put into the UDP tunnels list. This results in VxLAN and Geneve tunnel Rx offloads being essentially disabled, unless the port number happens to be identical after byte swapping. Note that i40e_aq_add_udp_tunnel() will byteswap the parameter from host order into Little Endian so we don't need worry about passing strictly a __le16 value to the command. This patch essentially reverts b3f5c7bc88ba ("i40e: Fix for extra byte swap in tunnel setup", 2016-08-24), but in a way that makes the result much more clear to the reader. Fixes: b3f5c7bc88ba ("i40e: Fix for extra byte swap in tunnel setup", 2016-08-24) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Williams, Mitch A <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-15mqprio: Modify mqprio to pass user parameters via ndo_setup_tc.Amritha Nambiar
The configurable priority to traffic class mapping and the user specified queue ranges are used to configure the traffic class, overriding the hardware defaults when the 'hw' option is set to 0. However, when the 'hw' option is non-zero, the hardware QOS defaults are used. This patch makes it so that we can pass the data the user provided to ndo_setup_tc. This allows us to pull in the queue configuration if the user requested it as well as any additional hardware offload type requested by using a value other than 1 for the hw value. Finally it also provides a means for the device driver to return the level supported for the offload type via the qopt->hw value. Previously we were just always assuming the value to be 1, in the future values beyond just 1 may be supported. Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-03-15i40e: rename auto_disable_flags to hw_disabled_flagsHarshitha Ramamurthy
A previous commit introduced a field that tracks the features that are disabled due to HW resource limitations as opposed to the featured disabled by the user. This patch changes the name of the field to make it more readable since it might get confusing when looking at code containing both the flags field and the auto_disable_features field together. Change-ID: Idcc9888659698f6fe3ccff17c8c3f09b5026f708 Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-15i40e/i40evf: Change version from 1.6.27 to 2.1.7Bimmy Pujari
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-15i40e: Clarify steps in MAC/VLAN filters initialization routineFilip Sadowski
This patch clarifies the reason for removal of automatically firmware-generated filter and explicit addition of filter which accepts frames with any VLAN id. Change-ID: Iabf180b6d61c4d8a36d3bcf8457c377a6f2aca0e 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>
2017-03-15i40e: fix RSS queues only operating on PF0Lihong Yang
This patch fixes the issue that RSS offloading only works on PF0 by using the direct register writing of the hash keys for the VFs instead of using the admin queue command to do so. Change-ID: Ia02cda7dbaa23def342e8786097a2c03db6f580b Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-15i40e: don't add more vectors to num_lan_msix than number of CPUsJacob Keller
This is a solution to avoid adding too many queues to num_lan_msix. A recent refactor of queue pairs accidentally added all remaining vectors to the num_lan_msix which can have adverse performance issues, due to enabling more queues than the number of CPU cores. This patch removes the old calculation, and replaces it with a simple algorithm. 1) add queue pairs up to num_online_cpus(), but capped at half of total vectors 2) then add alternative features such as flow directory and similar 3) finally, add the remaining vectors back to queue pairs, but capped such that the total number of queue pairs does not exceed num_online_cpus(). Change-ID: I668abf67d5011a1248866daba8885f4ff00cb8d9 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-03-15i40e: KISS the client interfaceMitch Williams
(KISS is Keep It Simple, Stupid. Or is it?) The client interface vastly overengineered for what it needs to do. It was originally designed to support multiple clients on multiple netdevs, possibly even with multiple drivers. None of this happened, and now we know that there will only ever be one client for i40e (i40iw) and one for i40evf (i40iwvf). So, time for some KISS. Since i40e and i40evf are a Dynasty, we'll simplify this one to match the VF interface. First, be a Destroyer and remove all of the lists and locks required to support multiple clients. Keep one static around to keep track of one client, and track the client instances for each netdev in the driver's pf (or adapter) struct. Now it's Almost Human. Since we already know the client type is iWarp, get rid of any checks for this. Same for VSI type - it's always going to be the same type, so it's just a Parasite. While we're at it, fix up some comments. This makes the function headers actually match the functions. These changes reduce code complexity, simplify maintenance, squash some lurking timing bugs, and allow us to Rock and Roll All Nite. Change-ID: I1ea79948ad73b8685272451440a34507f9a9012e Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> 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>
2017-02-18i40e: Invoke softirqs after napi_rescheduleBenjamin Poirier
The following message is logged from time to time when using i40e: NOHZ: local_softirq_pending 08 i40e may schedule napi from a workqueue. Afterwards, softirqs are not run in a deterministic time frame. The problem is the same as what was described in commit ec13ee80145c ("virtio_net: invoke softirqs after __napi_schedule") and this patch applies the same fix to i40e. Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2017-02-18i40e: remove duplicate device id from PCI tableCarolyn Wyborny
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>