Jacob Keller [Wed, 3 May 2017 17:29:04 +0000 (10:29 -0700)]
ixgbe: check for Tx timestamp timeouts during watchdog
The ixgbe driver has logic to handle only one Tx timestamp at a time,
using a state bit lock to avoid multiple requests at once.
It may be possible, if incredibly unlikely, that a Tx timestamp event is
requested but never completes. Since we use an interrupt scheme to
determine when the Tx timestamp occurred we would never clear the state
bit in this case.
Add an ixgbe_ptp_tx_hang() function similar to the already existing
ixgbe_ptp_rx_hang() function. This function runs in the watchdog routine
and makes sure we eventually recover from this case instead of
permanently disabling Tx timestamps.
Note: there is no currently known way to cause this without hacking the
driver code to force 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>
Orabug: 26785078
(cherry picked from commit 622a2ef538fb3ca8eccf49716aba8267d6e95a47) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Jacob Keller [Wed, 3 May 2017 17:28:56 +0000 (10:28 -0700)]
ixgbe: avoid permanent lock of *_PTP_TX_IN_PROGRESS
The ixgbe driver uses a state bit lock to avoid handling more than one Tx
timestamp request at once. This is required because hardware is limited
to a single set of registers for Tx timestamps.
The state bit lock is not properly cleaned up during
ixgbe_xmit_frame_ring() if the transmit fails such as due to DMA or TSO
failure. In some hardware this results in blocking timestamps until the
service task times out. In other hardware this results in a permanent
lock of the timestamp bit because we never receive an interrupt
indicating the timestamp occurred, since indeed the packet was never
transmitted.
Fix this by checking for DMA and TSO errors in ixgbe_xmit_frame_ring() and
properly cleaning up after ourselves when these occur.
Reported-by: Reported-by: David Mirabito <davidm@metamako.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>
Orabug: 26785078
(cherry picked from commit 5fef124d9c75942dc5c2445a3faa8ad37cbf4c82) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Jacob Keller [Wed, 3 May 2017 17:28:53 +0000 (10:28 -0700)]
ixgbe: fix race condition with PTP_TX_IN_PROGRESS bits
Hardware related to the ixgbe driver is limited to handling a single Tx
timestamp request at a time. Thus, the driver ignores requests for Tx
timestamp while waiting for the current request to finish. It uses
a state bit lock which enforces that only one timestamp request is
honored at a time.
Unfortunately this suffers from a simple race condition. The bit lock is
not cleared until after skb_tstamp_tx() is called notifying applications
of a new Tx timestamp. Even a well behaved application sending only one
packet at a time and waiting for a response can wake up and send a new
packet before the bit lock is cleared. This results in needlessly
dropping some Tx timestamp requests.
We can fix this by unlocking the state bit as soon as we read the
Timestamp register, as this is the first point at which it is safe to
unlock.
To avoid issues with the skb pointer, we'll use a copy of the pointer
and set the global variable in the driver structure to NULL first. This
ensures that the next timestamp request does not modify our local copy
of the skb pointer.
This ensures that well behaved applications do not accidentally race
with the unlock bit. Obviously an application which sends multiple Tx
timestamp requests at once will still only timestamp one packet at
a time. Unfortunately there is nothing we can do about this.
Reported-by: David Mirabito <davidm@metamako.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>
Orabug: 26785078
(cherry picked from commit aaebaf50b502648b1d4d8c93b4be133944c2bbd0) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
skb->sender_cpu and skb->napi_id share a common storage,
and we had various bugs about this.
We had to call skb_sender_cpu_clear() in some places to
not leave a prior skb->napi_id and fool netdev_pick_tx()
As suggested by Alexei, we could split the space so that
these errors can not happen.
0 value being reserved as the common (not initialized) value,
let's reserve [1 .. NR_CPUS] range for valid sender_cpu,
and [NR_CPUS+1 .. ~0U] for valid napi_id.
This will allow proper busy polling support over tunnels.
Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ethan Zhao <ethan.zhao@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
When creating kernel-ueknano package, the files (modules) to be included in
it are supplied from a input file. This input file lists the modules with
install path. When installing the rpm, parent directories for these
files are created automatically. When uninstalling, the modules get removed
but not the parent directories. Because of this, /lib/modules/<kversion>/kernel
and its subdirectories are left intact even after the package uninstall.
This commit adds post uninstall scriptlet to remove the
"/lib/modules/<kversion>/" directory when the package is uninstalled.
Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Jacob Keller [Fri, 1 Sep 2017 20:43:08 +0000 (13:43 -0700)]
i40e: point wb_desc at the nvm_wb_desc during i40e_read_nvm_aq
When introducing the functions to read the NVM through the AdminQ, we
did not correctly mark the wb_desc.
Fixes: 7073f46e443e ("i40e: Add AQ commands for NVM Update for X722", 2015-06-05) 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>
Orabug: 26785018
(cherry picked from commit 3c8f3e96af3a6799841761923d000566645f0942) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
i40e: avoid NVM acquire deadlock during NVM update
X722 devices use the AdminQ to access the NVM, and this requires taking
the AdminQ lock. Because of this, we lock the AdminQ during
i40e_read_nvm(), which is also called in places where the lock is
already held, such as the firmware update path which wants to lock once
and then unlock when finished after performing several tasks.
Although this should have only affected X722 devices, commit 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices",
2016-12-02) added locking for all NVM reads, regardless of device
family.
This resulted in us accidentally causing NVM acquire timeouts on all
devices, causing failed firmware updates which left the eeprom in
a corrupt state.
Create unsafe non-locked variants of i40e_read_nvm_word and
i40e_read_nvm_buffer, __i40e_read_nvm_word and __i40e_read_nvm_buffer
respectively. These variants will not take the NVM lock and are expected
to only be called in places where the NVM lock is already held if
needed.
Since the only caller of i40e_read_nvm_buffer() was in such a path,
remove it entirely in favor of the unsafe version. If necessary we can
always add it back in the future.
Additionally, we now need to hold the NVM lock in i40e_validate_checksum
because the call to i40e_calc_nvm_checksum now assumes that the NVM lock
is held. We can further move the call to read I40E_SR_SW_CHECKSUM_WORD
up a bit so that we do not need to acquire the NVM lock twice.
This should resolve firmware updates and also fix potential raise that
could have caused the driver to report an invalid NVM checksum upon
driver load.
Reported-by: Stefan Assmann <sassmann@kpanic.de> Fixes: 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices", 2016-12-02) Signed-off-by: Anjali Singhai Jain <anjali.singhai@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>
Orabug: 26785018
(cherry picked from commit 09f79fd49d94cda5837e9bfd0cb222232b3b6d9f) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 14 Jul 2017 13:10:13 +0000 (09:10 -0400)]
i40e/i40evf: avoid dynamic ITR updates when polling or low packet rate
The dynamic ITR algorithm depends on a calculation of usecs which
assumes that the interrupts have been firing constantly at the interrupt
throttle rate. This is not guaranteed because we could have a low packet
rate, or have been polling in software.
We'll estimate whether this is the case by using jiffies to determine if
we've been too long. If the time difference of jiffies is larger we are
guaranteed to have an incorrect calculation. If the time difference of
jiffies is smaller we might have been polling some but the difference
shouldn't affect the calculation too much.
This ensures that we don't get stuck in BULK latency during certain rare
situations where we receive bursts of packets that force us into NAPI
polling.
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>
Orabug: 26785018
(cherry picked from commit 742c9875759c1858c3312442a78a80f3e93d82c4) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 14 Jul 2017 13:10:12 +0000 (09:10 -0400)]
i40e/i40evf: remove ULTRA latency mode
Since commit c56625d59726 ("i40e/i40evf: change dynamic interrupt
thresholds") a new higher latency ITR setting called I40E_ULTRA_LATENCY
was added with a cryptic comment about how it was meant for adjusting Rx
more aggressively when streaming small packets.
This mode was attempting to calculate packets per second and then kick
in when we have a huge number of small packets.
Unfortunately, the ULTRA setting was kicking in for workloads it wasn't
intended for including single-thread UDP_STREAM workloads.
This wasn't caught for a variety of reasons. First, the ip_defrag
routines were improved somewhat which makes the UDP_STREAM test still
reasonable at 10GbE, even when dropped down to 8k interrupts a second.
Additionally, some other obvious workloads appear to work fine, such
as TCP_STREAM.
The number 40k doesn't make sense for a number of reasons. First, we
absolutely can do more than 40k packets per second. Second, we calculate
the value inline in an integer, which sometimes can overflow resulting
in using incorrect values.
If we fix this overflow it makes it even more likely that we'll enter
ULTRA mode which is the opposite of what we want.
The ULTRA mode was added originally as a way to reduce CPU utilization
during a small packet workload where we weren't keeping up anyways. It
should never have been kicking in during these other workloads.
Given the issues outlined above, let's remove the ULTRA latency mode. If
necessary, a better solution to the CPU utilization issue for small
packet workloads will be added in a future patch.
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>
Orabug: 26785018
(cherry picked from commit 0a2c7722be1705edca34458bd9de2f97188f9636) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 14 Jul 2017 13:10:11 +0000 (09:10 -0400)]
i40e: invert logic for checking incorrect cpu vs irq affinity
In commit 96db776a3682 ("i40e/vf: fix interrupt affinity bug")
we added some code to force exit of polling in case we did
not have the correct CPU. This is important since it was possible for
the IRQ affinity to be changed while the CPU is pegged at 100%. This can
result in the polling routine being stuck on the wrong CPU until
traffic finally stops.
Unfortunately, the implementation, "if the CPU is correct, exit as
normal, otherwise, fall-through to the end-polling exit" is incredibly
confusing to reason about. In this case, the normal flow looks like the
exception, while the exception actually occurs far away from the if
statement and comment.
We recently discovered and fixed a bug in this code because we were
incorrectly initializing the affinity mask.
Re-write the code so that the exceptional case is handled at the check,
rather than having the logic be spread through the regular exit flow.
This does end up with minor code duplication, but the resulting code is
much easier to reason about.
The new logic is identical, but inverted. If we are running on a CPU not
in our affinity mask, we'll exit polling. However, the code flow is much
easier to understand.
Note that we don't actually have to check for MSI-X, because in the MSI
case we'll only have one q_vector, but its default affinity mask should
be correct as it includes all CPUs when it's initialized. Further, we
could at some point add code to setup the notifier for the non-MSI-X
case and enable this workaround for that case too, if desired, though
there isn't much gain since its unlikely to be the common case.
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>
Orabug: 26785018
(cherry picked from commit 6d9777298b54bf1212fcaa6ee6679a430ceca452) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 14 Jul 2017 13:10:10 +0000 (09:10 -0400)]
i40e: initialize our affinity_mask based on cpu_possible_mask
On older kernels a call to irq_set_affinity_hint does not guarantee that
the IRQ affinity will be set. If nothing else on the system sets the IRQ
affinity this can result in a bug in the i40e_napi_poll() routine where
we notice that our interrupt fired on the "wrong" CPU according to our
internal affinity_mask variable.
This results in a bug where we continuously tell NAPI to stop polling to
move the interrupt to a new CPU, but the CPU never changes because our
affinity mask does not match the actual mask setup for the IRQ.
The root problem is a mismatched affinity mask value. So lets initialize
the value to cpu_possible_mask instead. This ensures that prior to the
first time we get an IRQ affinity notification we'll have the mask set
to include every possible CPU.
We use cpu_possible_mask instead of cpu_online_mask since the former is
almost certainly never going to change, while the later might change
after we've made a copy.
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>
Orabug: 26785018
(cherry picked from commit 759dc4a7e605e0dc21708b0a6e0816ed0ac82641) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 14 Jul 2017 13:10:09 +0000 (09:10 -0400)]
i40e: move enabling icr0 into i40e_update_enable_itr
If we don't have MSI-X enabled, we handle interrupts on all icr0. This
is a special case, so let's move the conditional into
i40e_update_enable_itr() in order to make i40e_napi_poll easier to
read about.
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>
Orabug: 26785018
(cherry picked from commit 9254c0e34e4253c41fdcd4670b754506ce20d3eb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
i40e: Fix for unused value issue found by static analysis
This patch fixes an issue where an error return value is
set, but without an immediate exit, the value can be overwritten
by the following code execution. The condition at this point
is not fatal, so remove the error assignment and comment the
intent for future code maintainers
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>
Orabug: 26785018
(cherry picked from commit 19279235bea221798e3307a8bec2c02559cab0c5) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 12 Jul 2017 09:46:12 +0000 (05:46 -0400)]
i40e: force VMDQ device name truncation
In new versions of GCC since 7.x a new warning exists which warns when
a string is truncated before all of the format can be completed.
When we setup VMDQ netdev names we are copying a pre-existing interface
name which could be up to 15 characters in length. Since we also add
4 bytes, v, the literal %, the d and a \0 null, we would overrun the
available size unless snprintf truncated for us.
The snprintf call will of course truncate on the end, so lets instead
modify the code to force truncation of the copied netdev name by
4 characters, to create enough space for the 4 bytes we're adding.
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>
Orabug: 26785018
(cherry picked from commit 8c9eb350aa7b66ab06f3e378dab3c7875a0bf83a) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 12 Jul 2017 09:46:11 +0000 (05:46 -0400)]
i40evf: fix possible snprintf truncation of q_vector->name
The q_vector names are based on the interface name with a driver prefix,
the type of q_vector setup, and the queue number. We previously set the
size of this variable to IFNAMSIZ + 9, which is incorrect, because we
actually include a minimum of 14 characters extra beyond the interface
name size.
New versions of GCC since 7 include a new warning that detects this
possible truncation and complains. We can fix this by increasing the
size in case our interface name is too large to avoid truncation. We
don't need to go beyond 14 because the compiler is smart enough to
realize our values can never exceed size of 1. We do go up to 15 here
because possible future changes may increase the number of queues beyond
one digit.
While we are here, also change some variables to be unsigned (since they
are never negative) and stop using an extra unnecessary %s format
specifier.
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>
Orabug: 26785018
(cherry picked from commit 696ac80aa11fb80e641068123412cd397b460a0b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
i40e: Use correct flag to enable egress traffic for unicast promisc
Albeit, we usually set true promiscuous mode for both multicast and
unicast at the same time - however, it is possible to set it
individually, so using allmulti flag which is only for allmulticast might
caused unwanted behavior in mirroring egress traffic promiscuous for
unicast in VF.
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit e53b382f3a207690fc0411a3b39fbd21d7470cfc) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 12 Jul 2017 09:46:09 +0000 (05:46 -0400)]
i40e: prevent snprintf format specifier truncation
Increase the size of the prefix buffer so that it can hold enough
characters for every possible input. Although 20 is enough for all
expected inputs, it is possible for the values to be larger than
expected, resulting in a possibly truncated string. Additionally, lets
use sizeof(prefix) in order to ensure we use the correct size if we need
to change the array length in the future.
New versions of GCC starting at 7 now include warnings to prevent
truncation unless you handle the return code. At most 27 bytes can be
written here, so lets just increase the buffer size even if for all
expected hw->bus.* values we only needed 20.
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>
Orabug: 26785018
(cherry picked from commit b5d5504aa1e961fc1f87ee7b092bf5ce1a7bf0de) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Store information about FEC modes, that were requested. It will be used
in printing link status information function and this way there is no
need to call admin queue there.
Signed-off-by: Mariusz Stachura <mariusz.stachura@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit ed601f660131be6bb9a8a109b0f2bf031786100f) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Sudheer Mogilappagari [Sun, 27 Aug 2017 22:07:47 +0000 (15:07 -0700)]
i40e: Update state variable for adminq subtask
During NVM update, state machine gets into unrecoverable state because
i40e_clean_adminq_subtask can get scheduled after the admin queue
command but before other state variables are updated. This causes
incorrect input to i40e_nvmupd_check_wait_event and state transitions
don't happen.
This fix updates the state variables so that adminq_subtask will have
accurate information whenever it gets scheduled.
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>
Orabug: 26785018
(cherry picked from commit 167d52edc4991e81012ef571643d0307aa2bb916) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
i40e: synchronize nvmupdate command and adminq subtask
During NVM update, state machine gets into unrecoverable state because
i40e_clean_adminq_subtask can get scheduled after the admin queue
command but before other state variables are updated. This causes
incorrect input to i40e_nvmupd_check_wait_event and state transitions
don't happen.
This issue existed before but surfaced after commit 373149fc99a0
("i40e: Decrease the scope of rtnl lock")
This fix adds locking around admin queue command and update of
state variables so that adminq_subtask will have accurate information
whenever it gets scheduled.
Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 2bf01935ec5362aee6ff9ffc2476043af321aa42) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Alan Brady [Wed, 12 Jul 2017 09:46:06 +0000 (05:46 -0400)]
i40e: prevent changing ITR if adaptive-rx/tx enabled
Currently the driver allows the user to change (or even disable)
interrupt moderation if adaptive-rx/tx is enabled when this should
not be the case.
Adaptive RX/TX will not respect the user's ITR settings so
allowing the user to change it is weird. This bug would also
allow the user to disable interrupt moderation with adaptive-rx/tx
enabled which doesn't make much sense either.
This patch makes it such that if adaptive-rx/tx is enabled, the user
cannot make any manual adjustments to interrupt moderation. It also
makes it so that if ITR is disabled but adaptive-rx/tx is then
enabled, ITR will be re-enabled.
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>
Orabug: 26785018
(cherry picked from commit 06b2decd924891b6c7570a91f91e11a5a8fed421) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 23 Jun 2017 08:24:51 +0000 (04:24 -0400)]
i40e: move check for avoiding VID=0 filters into i40e_vsi_add_vlan
In i40e_vsi_add_vlan we treat attempting to add VID=0 as an error,
because it does not do what the caller might expect. We already special
case VID=0 in i40e_vlan_rx_add_vid so that we avoid this error when
adding the VLAN.
This special casing is necessary so that we do not add the VLAN=0 filter
since we don't want to stop receiving untagged traffic. Unfortunately,
not all callers of i40e_vsi_add_vlan are aware of this, including when
we add VLANs from a VF device.
Rather than special casing every single caller of i40e_vsi_add_vlan,
lets just move this check internally. This makes the code simpler
because the caller does not need to be aware of how VLAN=0 is special,
and we don't forget to add this check in new places.
This fixes a harmless error message displaying when adding a VLAN from
within a VF. The message was meaningless but there is no reason to
confuse end users and system administrators, and this is now avoided.
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>
Orabug: 26785018
(cherry picked from commit fcf6cfc8a695bd82d123166aeedab9fa12720b57) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Fri, 23 Jun 2017 08:24:50 +0000 (04:24 -0400)]
i40e/i40evf: use cmpxchg64 when updating private flags in ethtool
When a user gives an invalid command to change a private flag which is
not supported, either because it is read-only, or the device is not
capable of the feature, we simply ignore the request.
A naive solution would simply be to report error codes when one of the
flags was not supported. However, this causes problems because it makes
the operation not atomic. If a user requests multiple private flags
together at once we could end up changing one before failing at the
second flag.
We can do a bit better if we instead update a temporary copy of the
flags variable in the loop, and then copy it into place after. If we
aren't careful this has the pitfall of potentially silently overwriting
any changes caused by other threads.
Avoid this by using cmpxchg64 which will compare and swap the flags
variable only if it currently matched the old value. We'll report
-EAGAIN in the (hopefully rare!) case where the cmpxchg64 fails.
This ensures that we can properly report when flags are not supported in
an atomic fashion without the risk of overwriting other threads changes.
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>
Orabug: 26785018
(cherry picked from commit 841c950d67c6facde32a8644ced20c04aebb7dd8) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
i40e: Detect ATR HW Evict NVM issue and disable the feature
This patch fixes a problem with the HW ATR eviction feature where the
NVM setting was incorrect. This patch detects the issue on X720
adapters and disables the feature if the NVM setting is incorrect.
Without this patch, HW ATR Evict feature does not work on broken NVMs
and is not detected either. If the HW ATR Evict feature is disabled
the SW Eviction feature will take effect.
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> 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>
Orabug: 26785018
(cherry picked from commit 10a955ff62e56fe13dae1f29aabc04bc589eaf46) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
The X722 pf flag setup should happen before the VMDq RSS queue count is
initialized for VMDq VSI to get the right number of queues for RSS in
case of X722 devices.
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> 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>
Orabug: 26785018
(cherry picked from commit 5a433199bfde1b5360bf592184a2b89ce4ee2eda) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Sudheer Mogilappagari [Fri, 23 Jun 2017 08:24:44 +0000 (04:24 -0400)]
i40evf: prevent VF close returning before state transitions to DOWN
Currently i40evf_close() can return before state transitions to
__I40EVF_DOWN because of the latency involved in processing and
receiving response from PF driver and scheduling of VF watchdog_task.
Due to this inconsistency an immediate call to i40evf_open() fails
because state is still DOWN_PENDING.
When a VF interface is in up state and we try to add it as slave,
The bonding driver calls dev_close() and dev_open() in short duration
resulting in dev_open returning error. The ifenslave command needs
to be run again for dev_open to succeed.
This fix ensures that watchdog timer is scheduled immediately after
admin queue operations are scheduled in i40evf_down(). In addition a
wait condition is added at the end of i40evf_close so that function
wont return when state is still DOWN_PENDING. The timeout value is
chosen after some profiling and includes some buffer.
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>
Orabug: 26785018
(cherry picked from commit fe2647ab0c9970cfc2895f1671343c23fed27f44) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Florian Fainelli [Tue, 1 Aug 2017 19:11:07 +0000 (12:11 -0700)]
i40e: Initialize 64-bit statistics TX ring seqcount
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.
Fixes: 980e9b118642 ("i40e: Add support for 64 bit netstats") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 26785018
(cherry picked from commit 7d6d067790289e4f61f59fa60550ca5918aa25bd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Stefan Assmann [Fri, 23 Jun 2017 07:46:24 +0000 (09:46 +0200)]
i40e: handle setting administratively set MAC address back to zero
When an administratively set MAC was previously set and should now be
switched back to 00:00:00:00:00:00 the pf_set_mac flag did not get
toggled back to false.
As a result VFs were still treated as if an administratively set MAC was
present.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 2f1d86e44c9dac948a79ee7543426e00230564ab) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Tue, 20 Jun 2017 22:17:00 +0000 (15:17 -0700)]
i40e: display correct UDP tunnel type name
The i40e driver attempts to display the UDP tunnel name by doing a check
against the type, where for non-zero types we use "vxlan" and for zero
type we use "geneve". This is not future proof, because if new tunnel
types get added, we'll incorrectly label them. It also depends on the
value of UDP_TUNNEL_TYPE_GENEVE == 0, which is brittle.
Instead, replace this with a function that can return a constant string
depending on the type. For now we'll use "unknown" for types we don't
know about, and we can expand this in the future if new types get added.
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>
Orabug: 26785018
(cherry picked from commit d8b2c700a3a07c7108d9031dc88a6298c101e05d) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jesse Brandeburg [Tue, 20 Jun 2017 22:16:57 +0000 (15:16 -0700)]
i40e: fix odd formatting and indent
The compiler warned on an oddly indented bit of code, and when
investigating that, noted that the functions themselves had
an odd flow. The if condition was checked, and would exclude
a call to AQ, but then the aq_ret would be checked unconditionally
which just looks really weird, and is likely to cause objections.
Signed-off-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>
Orabug: 26785018
(cherry picked from commit 4d433084dd3b8b9ce656c35505e7dc5bd1d929b5) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Paul M Stillwell Jr [Tue, 20 Jun 2017 22:16:55 +0000 (15:16 -0700)]
i40e: Handle admin Q timeout when releasing NVM
There are some rare cases where the release resource call will return an
admin Q timeout. In these cases the code needs to try to release the
resource again until it succeeds or it times out.
Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 981e25c32bc22bcaa429420c92bfec860008a1eb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Tue, 20 Jun 2017 22:16:54 +0000 (15:16 -0700)]
i40e: remove WQ_UNBOUND and the task limit of our workqueue
During certain events such as a CORER, multiple devices will run a work
task to handle some cleanup. This can cause issues due to
a single-threaded workqueue which can mean that a device doesn't cleanup
in time. Prevent this by removing the single-threaded restriction on the
module workqueue. This avoids the need to add more complex yielding
logic in our service task routine. This is also similar to what other
drivers such as fm10k do.
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>
Orabug: 26785018
(cherry picked from commit 4d5957cbdecdbb77d24c1465caadd801c07afa4a) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Carolyn Wyborny [Tue, 20 Jun 2017 22:16:53 +0000 (15:16 -0700)]
i40e: Fix for trace found with S4 state
This patch fixes a problem found in systems when entering
S4 state. This patch fixes the problem by ensuring that
the misc vector's IRQ is disabled as well. Without this
patch a stack trace can be seen upon entering S4 state.
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>
Orabug: 26785018
(cherry picked from commit 7c9ae7f053e9e896c24fd23595ba369a5fe322e1) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Gustavo A R Silva [Thu, 15 Jun 2017 02:38:26 +0000 (21:38 -0500)]
i40e: fix incorrect variable assignment
Fix incorrect variable assignment.
Based on line 1511: aq_ret = I40_ERR_PARAM; the correct variable to be
used in this instance is aq_ret instead of ret. Also, variable ret is
updated at line 1602 just before return, so assigning a value to this
variable in this code block is useless.
Addresses-Coverity-ID: 1397693 Signed-off-by: Gustavo A R Silva <garsilva@embeddedor.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>
Orabug: 26785018
(cherry picked from commit db1a8f8e833037a8ed0f333243d0c90d18acb62f) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 7 Jun 2017 09:43:13 +0000 (05:43 -0400)]
i40e: don't hold RTNL lock for the entire reset
We recently refactored i40e_do_reset() and its friends to be able to
hold the RTNL lock only for the portions that actually need to be
protected. However, a separate refactoring added several new callers of
these functions during the PCIe error recovery and suspend/resume
cycles.
When merging the changes together, it was not noticed that we could
reduce the RTNL scope by letting the reset function handle the lock
itself, as previously it was not possible.
Fix this by replacing these call sites to indicate that the reset
function should handle its own lock. This enables multiple PFs to reset
or resume simultaneously without serializing the resets via the RTNL
lock. The end result is that on systems with lots of PFs and VFs the
resets don't stall waiting for each other to finish.
It is probable that we can also do the same for i40e_do_reset_safe, but
this author did not research that change carefully enough to be
confident.
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>
Orabug: 26785018
(cherry picked from commit dfc4ff644674a133878aded9a86ab36c358f3138) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Shannon Nelson [Wed, 7 Jun 2017 09:43:11 +0000 (05:43 -0400)]
i40e: clear only cause_ena bit
When disabling interrupts, we should only be clearing the CAUSE_ENA bit,
not clearing the whole register. Clearing the whole register sets the
NEXTQ_IDX field to 0 instead of 0x7ff which can confuse the Firmware in
some reset sequences.
Signed-off-by: Shannon Nelson <shannon.nelson@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>
Orabug: 26785018
(cherry picked from commit 2e5c26ea0d0843074a1b8c868aae5c828c155569) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Alan Brady [Wed, 7 Jun 2017 09:43:10 +0000 (05:43 -0400)]
i40e: fix disabling overflow promiscuous mode
There exists a bug in which the driver does not correctly exit overflow
promiscuous mode. This can occur if "too many" mac filters are added,
putting the driver into overflow promiscuous mode, and the filters are
then removed. When the failed filters are removed, the driver reports
exiting overflow promiscuous mode which is correct, however traffic
continues to be received as if in promiscuous mode still.
The bug occurs because the conditional for toggling promiscuous mode was
set to only execute when promiscuous mode was enabled and not when it
was disabled as well. This patch fixes the conditional to correctly
execute when promiscuous mode is toggled and not just enabled. Without
this patch, the driver is unable to correctly exit overflow promiscuous
mode.
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>
Orabug: 26785018
(cherry picked from commit e588723986845457942e8a1acb1e31cf18e8eb08) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Filip Sadowski [Wed, 7 Jun 2017 09:43:09 +0000 (05:43 -0400)]
i40e: Add support for OEM firmware version
This patch adds support for OEM firmware version. If OEM specific
adapter is detected ethtool reports OEM product version in firmware
version string instead of etrack id.
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>
Orabug: 26785018
(cherry picked from commit 5bbb2e2045449706a6daf092e5727998e4984c0b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Shannon Nelson [Wed, 7 Jun 2017 09:43:08 +0000 (05:43 -0400)]
i40e: genericize the partition bandwidth control
Partition bandwidth control is not in just one form of MFP (multi-function
partitioning), so make the code more generic and be sure to nudge the Tx
scheduler for all MFP.
Copyright updated to 2017.
Signed-off-by: Shannon Nelson <shannon.nelson@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>
Orabug: 26785018
(cherry picked from commit 4fc8c67639575e38fff41bb4bd01c601aba930ff) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Greg Bowers [Wed, 7 Jun 2017 09:43:06 +0000 (05:43 -0400)]
i40e: Support firmware CEE DCB UP to TC map re-definition
Changes parsing of FW 4.33 AQ command Get CEE DCBX OPER CFG (0x0A07).
Change is required because FW now creates the oper_prio_tc
nibbles reversed from those in the CEE Priority Group sub-TLV.
This change will only apply to FW 4.33 as future FW versions will use a
different function to parse the CEE data.
Signed-off-by: Greg Bowers <gregory.j.bowers@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 68fb13a7677475e5470ef6aba585da5c609ea2cb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Sudheer Mogilappagari [Wed, 7 Jun 2017 09:43:05 +0000 (05:43 -0400)]
i40e: Fix potential out of bound array access
This is a fix for the static code analysis issue where dcbcfg->numapps
could be greater than size of array (i.e dcbcfg->app[I40E_DCBX_MAX_APPS]).
The fix makes sure that the array is not accessed past the size of
of the array (i.e. I40E_DCBX_MAX_APPS).
Copyright updated to 2017.
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>
Orabug: 26785018
(cherry picked from commit 1e99854715c79b3e2ebe09d80006aaff0f5c2335) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 7 Jun 2017 09:43:04 +0000 (05:43 -0400)]
i40e: comment that udp_port must be in host byte order
The firmware expects the port number passed when setting up
the UDP tunnel configuration to be in Little Endian format.
The i40e_aq_add_udp_tunnel command byte swaps the value from
host order to Little Endian.
Since commit fe0b0cd97b4f ("i40e: send correct port number to
AdminQ when enabling UDP tunnels") we've correctly
sent the value in host order.
Let's also add a comment to the function explaining that it must
be in host order, as the port numbers are commonly stored as Big
Endian values.
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>
Orabug: 26785018
(cherry picked from commit 15d23b4c361f1449d44249bea127d2bdb981aa01) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 7 Jun 2017 09:43:03 +0000 (05:43 -0400)]
i40e: use dev_dbg instead of dev_info when warning about missing routine
When searching for the vf_capability client routine, dev_info() was
used, instead of the normal dev_dbg(). This causes the message to be
displayed at standard log levels which can cause administrators to
worry. Avoid this by using dev_dbg instead.
Copyright updated to 2017.
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>
Orabug: 26785018
(cherry picked from commit 59e331e36ef934791947a616cc578bf3c62a019c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Alice Michael [Wed, 7 Jun 2017 09:43:02 +0000 (05:43 -0400)]
i40e/i40evf: update WOL and I40E_AQC_ADDR_VALID_MASK flags
Update a few flags related to FW interactions.
Copyright updated to 2017.
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>
Orabug: 26785018
(cherry picked from commit 7c32b1e650752408a8dcc7a85f1776c2e24ea1da) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
The variable num_active_queues represents the number of active queues we
have for the device. We assign this pretty early in i40evf_init_subtask.
Several code locations are written with loops over the tx_rings and
rx_rings structures, which don't get allocated until
i40evf_alloc_queues, and which get freed by i40evf_free_queues.
These call sites were written under the assumption that tx_rings and
rx_rings would always be allocated at least when num_active_queues is
non-zero.
Lets fix this by moving the assignment into the function where we
allocate queues. We'll use a temporary variable for storage so that we
don't assign the value in the adapter structure until after the rings
have been set up.
Finally, when we free the queues, we'll clear the value to ensure that
we do not loop over the rings memory that no longer exists.
This resolves a possible NULL pointer dereference in
i40evf_get_ethtool_stats which could occur if the VF fails to recover
from a reset, and then a user requests statistics.
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>
Orabug: 26785018
(cherry picked from commit 65c7006f234c9ede887d468f595f259a5c5cc552) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jia-Ju Bai [Wed, 14 Jun 2017 23:35:31 +0000 (16:35 -0700)]
i40e: Fix a sleep-in-atomic bug
The driver may sleep under a spin lock, and the function call path is:
i40e_ndo_set_vf_port_vlan (acquire the lock by spin_lock_bh)
i40e_vsi_remove_pvid
i40e_vlan_stripping_disable
i40e_aq_update_vsi_params
i40e_asq_send_command
mutex_lock --> may sleep
To fixed it, the spin lock is released before "i40e_vsi_remove_pvid", and
the lock is acquired again after this function.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.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>
Orabug: 26785018
(cherry picked from commit 640f93cc6ea7327588be3cc0849d1342aac0393a) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Mon, 12 Jun 2017 22:38:36 +0000 (15:38 -0700)]
i40e: fix handling of HW ATR eviction
A recent commit to refactor the driver and remove the hw_disabled_flags
field accidentally introduced two regressions. First, we overwrote
pf->flags which removed various key flags including the MSI-X settings.
Additionally, it was intended that we have now two flags,
HW_ATR_EVICT_CAPABLE and HW_ATR_EVICT_ENABLED, but this was not done,
and we accidentally were mis-using HW_ATR_EVICT_CAPABLE everywhere.
This patch adds the missing piece, HW_ATR_EVICT_ENABLED, and safely
updates pf->flags instead of overwriting it.
Without this patch we will have many problems including disabling MSI-X
support, and we'll attempt to use HW ATR eviction on devices which do
not support it.
Fixes: 47994c119a36 ("i40e: remove hw_disabled_flags in favor of using separate flag bits", 2017-04-19) 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> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 26785018
(cherry picked from commit 6964e53f55837b0c49ed60d36656d2e0ee4fc27b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jesse Brandeburg [Thu, 11 May 2017 18:23:08 +0000 (11:23 -0700)]
i40evf: drop i40e_type.h include
This drops the i40e_type.h include in anticipation of the next
patch which moves this file to a location where type.h doesn't
exist, and all the places this file is included already include
i40e_type.h before this file.
Signed-off-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>
Orabug: 26785018
(cherry picked from commit 392908033308892b9da71551a65b4e59c5006b1c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 3 May 2017 17:29:02 +0000 (10:29 -0700)]
i40e: check for Tx timestamp timeouts during watchdog
The i40e driver has logic to handle only one Tx timestamp at a time,
using a state bit lock to avoid multiple requests at once.
It may be possible, if incredibly unlikely, that a Tx timestamp event is
requested but never completes. Since we use an interrupt scheme to
determine when the Tx timestamp occurred we would never clear the state
bit in this case.
Add an i40e_ptp_tx_hang() function similar to the already existing
i40e_ptp_rx_hang() function. This function runs in the watchdog routine
and makes sure we eventually recover from this case instead of
permanently disabling Tx timestamps.
Note: there is no currently known way to cause this without hacking the
driver code to force it.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 0bc0706b46cd345537f9bd3cdf5d84c33f5484e4) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 3 May 2017 17:29:01 +0000 (10:29 -0700)]
i40e: use pf data structure directly in i40e_ptp_rx_hang
There's no reason to pass a *vsi pointer if we already have the *pf
pointer in the only location where we call this function. Lets update
the signature and directly pass the *pf data structure pointer.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 61189556692e8e58c97e764d6b3f24db5cd243de) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 3 May 2017 17:28:54 +0000 (10:28 -0700)]
i40e: avoid permanent lock of *_PTP_TX_IN_PROGRESS
The i40e driver uses a bit lock to indicate when a Tx timestamp is in
progress to avoid attempting to timestamp multiple packets at once. This
is required because hardware only has registers to handle one request at
a time.
There is a corner case where we failed to cleanup the bit lock after
a failed transmit. This can potentially result in a state bit being
locked forever.
Add some cleanup code to i40e_xmit_frame_ring to check and make sure we
cleanup incase of these failures. We also modify i40e_tx_map to return
an error code indication DMA failure.
Reported-by: Reported-by: David Mirabito <davidm@metamako.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit 69077577af5054da8c8adfb6c1ebb565c2f1f158) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 3 May 2017 17:28:51 +0000 (10:28 -0700)]
i40e: fix race condition with PTP_TX_IN_PROGRESS bits
Hardware related to the i40e driver has a limitation on Tx PTP packets.
This requires us to limit the driver to timestamping a single packet at
once. This is done using a state bitlock which enforces that only one
timestamp request is honored at a time.
Unfortunately this suffers from a race condition. The bit lock is not
cleared until after skb_tstamp_tx() is called notifying applications of
a new Tx timestamp. Even a well behaved application sending only one
packet at a time and waiting for a response can wake up and send a new
timestamped packet request before the bit lock is cleared. This results
in needlessly dropping some Tx timestamp requests.
We can fix this by unlocking the state bit as soon as we read the
Timestamp register, as this is the first point at which it is safe to
timestamp another packet.
To avoid issues with the skb pointer, we'll use a copy of the pointer
and set the global variable in the driver structure to NULL first. This
ensures that the next timestamp request does not modify our local copy
of the skb pointer.
Now, a well behaved application which has at most one outstanding
timestamp request will not accidentally race with the driver unlock bit.
Obviously an application attempting to timestamp faster than one request
at a time will have some timestamp requests skipped. Unfortunately there
is nothing we can do about that.
Reported-by: David Mirabito <davidm@metamako.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26785018
(cherry picked from commit bbc4e7d273b594debbcccdf588085b3521365c50) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
The i40evf hardware doesn't have any way to ever report FCoE enabled
so just force the code to always report FCoE is disabled, remove the
unused defines, and mark the OP as reserved.
Signed-off-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>
Orabug: 26785018
(cherry picked from commit 9d68322e53e683e332c032def9854501f9cbf4e8) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
This patch fixes a missing line that was missed while merging,
which results in a driver feature in the VF not working to
enable RSS as a negotiated feature.
Fixes: 43a3d9ba34c9c ("i40evf: Allow PF driver to configure RSS") Signed-off-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>
Orabug: 26785018
(cherry picked from commit 155b0f690051345deefc653774b739c786067d61) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
On architectures with larger pages, we get a warning about an unused variable:
drivers/net/ethernet/intel/i40evf/i40evf_main.c: In function 'i40evf_configure_rx':
drivers/net/ethernet/intel/i40evf/i40evf_main.c:690:21: error: unused variable 'netdev' [-Werror=unused-variable]
This moves the declaration into the #ifdef to avoid the warning.
Fixes: dab86afdbbd1 ("i40e/i40evf: Change the way we limit the maximum frame size for Rx") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-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>
Orabug: 26785018
(cherry picked from commit 3dfc3eb581645bc503c7940861f494a0d75615da) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 19 Apr 2017 13:25:59 +0000 (09:25 -0400)]
i40evf: allocate queues before we setup the interrupts and q_vectors
This matches the ordering of how we free stuff during reset and remove.
It also makes logical sense because we set the interrupts based on the
number of queues. Currently this doesn't really matter in practice.
However a future patch moves the assignment of num_active_queues into
i40evf_alloc_queues, which is required by
i40evf_set_interrupt_capability.
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>
Orabug: 26785018
(cherry picked from commit 283aeafe6bf06af48068478eaf332f7a227e9af4) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 19 Apr 2017 13:25:58 +0000 (09:25 -0400)]
i40evf: remove I40E_FLAG_FDIR_ATR_ENABLED
The flag used by the common code and PF code is I40E_FLAG_FD_ATR_ENABLED,
not *FDIR*. It turns out none of the txrx code actually shared with the
VF driver actually checks the ATR flag. This is made even more obvious
by the typo in the VF header file.
Let's just remove the flag from the VF driver since it's not needed.
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>
Orabug: 26785018
(cherry picked from commit 707636c6481696c3b73209c9a7f8c482f0748373) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 19 Apr 2017 13:25:57 +0000 (09:25 -0400)]
i40e: remove hw_disabled_flags in favor of using separate flag bits
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>
Orabug: 26785018
(cherry picked from commit 47994c119a36e28e1779efabc92d6ab5329a6f75) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 19 Apr 2017 13:25:56 +0000 (09:25 -0400)]
i40evf: remove needless min_t() on num_online_cpus()*2
We already set pairs to the value of adapter->num_active_queues. This
value is limited by vsi_res->num_queue_pairs and num_online_cpus(). This
means that pairs by definition is already smaller than
num_online_cpus()*2, so we don't even need to bother with this check.
Lets just remove it and update the comment.
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>
Orabug: 26785018
(cherry picked from commit 789f38ca70e0b2848472aaf5f278aa3deabd4a4e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 19 Apr 2017 13:25:53 +0000 (09:25 -0400)]
i40e: remove unnecessary msleep() delay in i40e_free_vfs
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>
Orabug: 26785018
(cherry picked from commit 2318b4018a9c2773a13f4fdac64d5519679fc171) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Wed, 19 Apr 2017 13:25:52 +0000 (09:25 -0400)]
i40e: amortize wait time when disabling lots of VFs
Just as we do in i40e_reset_all_vfs, save some time when freeing VFs by
amortizing the wait time for stopping queues. We can use
i40e_vsi_stop_rings_no_wait() to begin the process of stopping all the
VF rings at once. Then, once we've started the process on each VF we can
begin waiting for the VFs to stop. This helps reduce the total wait time
by a large factor.
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>
Orabug: 26785018
(cherry picked from commit 707d088af33043642692d4522225cb9ca638e7ee) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Alexander Duyck [Wed, 19 Apr 2017 13:25:51 +0000 (09:25 -0400)]
i40e: Reprogram port offloads after reset
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>
Orabug: 26785018
(cherry picked from commit 1f190d9369487c1edfaea4d892231a62ea8206cc) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:55 +0000 (04:45 -0400)]
i40e: make use of i40e_reset_all_vfs when initializing new VFs
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>
Orabug: 26785018
(cherry picked from commit 1b48437028603ec51d5a1eb276c941c866375a3e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:54 +0000 (04:45 -0400)]
i40e: properly spell I40E_VF_STATE_* flags
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>
Orabug: 26785018
(cherry picked from commit 6322e63c35d68eac9c4a5ed59ea1c6d1e2746892) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:53 +0000 (04:45 -0400)]
i40e: use i40e_stop_rings_no_wait to implement PORT_SUSPENDED state
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>
Orabug: 26785018
(cherry picked from commit 3480756f2cb93c9245e831a4f46ff6ed19c41031) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:52 +0000 (04:45 -0400)]
i40e: reset all VFs in parallel when rebuilding PF
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>
Orabug: 26785018
(cherry picked from commit e4b433f4a74196476ccf226e450c4582428641c1) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:51 +0000 (04:45 -0400)]
i40e: split some code in i40e_reset_vf into helpers
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>
Orabug: 26785018
(cherry picked from commit 9dc2e417383815bc6b8239ae2714d145c167b5c8) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:50 +0000 (04:45 -0400)]
i40e: remove I40E_FLAG_IN_NETPOLL entirely
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>
Orabug: 26785018
(cherry picked from commit 1de81c2d07abeed32e9cbe54bf19a79c6fc8e3ff) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:49 +0000 (04:45 -0400)]
i40e: reduce wait time for adminq command completion
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>
Orabug: 26785018
(cherry picked from commit 9e3f23f44f3294f794802e3fee2ba03214451a95) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:48 +0000 (04:45 -0400)]
i40e: fix CONFIG_BUSY checks in i40e_set_settings function
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>
Orabug: 26785018
(cherry picked from commit e8d2f4c674571b2b2d8a58405196d4a390996e33) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:47 +0000 (04:45 -0400)]
i40e: factor out queue control from i40e_vsi_control_(tx|rx)
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>
Orabug: 26785018
(cherry picked from commit c768e490640dbb928d1c8a5f7b437a334d0cde44) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Jacob Keller [Thu, 13 Apr 2017 08:45:46 +0000 (04:45 -0400)]
i40e: don't hold RTNL lock while waiting for VF reset to finish
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>
Orabug: 26785018
(cherry picked from commit 024b05f4246e281ef50e019eff0fc53aedf069ac) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Scott Peterson [Thu, 13 Apr 2017 08:45:44 +0000 (04:45 -0400)]
i40e/i40evf: Add tracepoints
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>
Orabug: 26785018
(cherry picked from commit ed0980c4401a21148d2fb9f4f6dd6132a4cc7599) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Mitch Williams [Tue, 24 Jan 2017 18:23:59 +0000 (10:23 -0800)]
i40evf: add client interface
In preparation for upcoming RDMA-capable hardware, add a client
interface to the VF driver. This is a slightly-simplified version
of the PF client interface, with the names changed to protect the
innocent.
Due to the nature of the VF<->PF interactions, the client interface
sometimes needs to call back into itself to pass messages. Because
of this, we can't use the coarse-grained locking like the PF's
client interface uses. Instead, we handle all client interactions
in a separate thread so the watchdog can still run and process
virtual channel messages.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> 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>
Orabug: 26785018
(cherry picked from commit ed0e894de7c1339be55ca0dcc11783d923ac5248) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Mitch Williams [Wed, 12 Apr 2017 11:16:52 +0000 (07:16 -0400)]
i40e: dump VF information in debugfs
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>
Orabug: 26785018
(cherry picked from commit 3118025a070f3346a3f23cbb8e9039ff567a6c46) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
Alexander Duyck [Mon, 10 Apr 2017 09:18:43 +0000 (05:18 -0400)]
i40e: Fix support for flow director programming status
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>
Orabug: 26785018
(cherry picked from commit 0e626ff7ccbfc43c6cc4aeea611c40b899682382) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
alice michael [Thu, 6 Apr 2017 09:59:34 +0000 (05:59 -0400)]
i40e/i40evf: Remove VF Rx csum offload for tunneled packets
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>
Orabug: 26785018
(cherry picked from commit 53240e99dbbfe69a6b3ca808a6d15eea744be169) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
i40evf: Use net_device_stats from struct net_device
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>
Orabug: 26785018
(cherry picked from commit 4a0a3abfd951943f770f5306d32f8640f55568c4) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Kyle Fortin <kyle.fortin@oracle.com>
projects / users / jedix / linux-maple.git / log