]> www.infradead.org Git - users/jedix/linux-maple.git/log
users/jedix/linux-maple.git
8 years agoi40e: remove error_param_int label from i40e_vc_config_promiscuous_mode_msg
Jacob Keller [Tue, 25 Oct 2016 23:08:48 +0000 (16:08 -0700)]
i40e: remove error_param_int label from i40e_vc_config_promiscuous_mode_msg

Orabug: 24568124

This label is unnecessary, as are jumping to a block that checks aq_ret
and then immediately skipping it and returning. So just jump straight to
the error_param and remove this unnecessary label.

Also use goto error_param even in the last check for style consistency.

Change-ID: If487c7d10c4048e37c594e5eca167693aaed45f6
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>
(cherry picked from commit 7429c0bd0155c73e0c6ec8f16e440735209d24a5)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: Be much more verbose about what we can and cannot offload
Alexander Duyck [Wed, 21 Dec 2016 22:07:35 +0000 (17:07 -0500)]
i40evf: Be much more verbose about what we can and cannot offload

Orabug: 24568124

This change makes it so that we are much more robust about defining what we
can and cannot offload.  Previously we were performing no checks.  This
should bring us up to parity with the i40e PF driver.

In addition the device only supports GSO as long as the MSS is 64 or
greater.  We were not checking this so an MSS less than that was resulting
in Tx hangs.

Change-ID: If533553ec92fc6ba694eab6ac81fdaf3004f3592
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>
(cherry picked from commit 06fc016c43eac5d88a53677ed0db7e28a7a1b4bd)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Be much more verbose about what we can and cannot offload
Alexander Duyck [Tue, 25 Oct 2016 23:08:46 +0000 (16:08 -0700)]
i40e: Be much more verbose about what we can and cannot offload

Orabug: 24568124

This change makes it so that we are much more robust about defining what we
can and cannot offload.  Previously we were just checking for the L4 tunnel
header length, however there are other fields we should be verifying as
there are multiple scenarios in which we cannot perform hardware offloads.

In addition the device only supports GSO as long as the MSS is 64 or
greater.  We were not checking this so an MSS less than that was resulting
in Tx hangs.

Change-ID: I5e2fd5f3075c73601b4b36327b771c64fcb6c31b
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
(cherry picked from commit f114dca2533ca770aebebffb5ed56e5e7d1fb3fb)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/net/ethernet/intel/i40e/i40e_main.c

Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: removed unreachable code
Filip Sadowski [Tue, 11 Oct 2016 22:26:58 +0000 (15:26 -0700)]
i40e: removed unreachable code

Orabug: 24568124

Removed some of unnecessary if statements and unreachable code found by
static code analysis tool.
The return value of i40e_vsi_control_rings(..., false) is always 0. So,
test for non-zero will never be true. The function has been split into
"int i40e_vsi_start_rings()" and "void i40e_vsi_stop_rings()" for better
understanding.
Similarly, the function i40e_vsi_kill_vlan() never fails. So, checking
for return value is also unnecessary. Function definition changed to void.
The i40e_loopback_test() function is not implemented. The function and
all references to loopback testing were removed.

Change-ID: Id45cf66f6689ce2bc4e887de13f073e30e8431bd
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>
(cherry picked from commit 3aa7b74dbeedfb32406fec70cfd76d797209e8c9)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Implementation of ERROR state for NVM update state machine
Maciej Sosin [Tue, 11 Oct 2016 22:26:57 +0000 (15:26 -0700)]
i40e: Implementation of ERROR state for NVM update state machine

Orabug: 24568124

This patch adds I40E_NVMUPD_STATE_ERROR state for NVM update.
Without this patch driver has no possibility to return NVM image write
failure.This state is being set when ARQ rises error.
arq_last_status is also updated every time when ARQ event comes,
not only on error cases.

Change-ID: I67ce43ba22a240773c2821b436e96054db0b7c81
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>
(cherry picked from commit 81fa7c97bebd6e1a52c4e059eeffe18df5b3f11f)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix for division by zero
Michal Kosiarz [Tue, 11 Oct 2016 22:26:56 +0000 (15:26 -0700)]
i40e: Fix for division by zero

Orabug: 24568124

For some cases when reading from device are incorrect or image is
incorrect, this part of code causes crash due to division by zero.

Change-ID: I8961029a7a87b0a479995823ef8fcbf6471405e1
Signed-off-by: Michal Kosiarz <michal.kosiarz@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 999b315d39906341fadcb65ee6aba7f5cf38b830)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: clear mac filter count on reset
Mitch Williams [Tue, 11 Oct 2016 22:26:55 +0000 (15:26 -0700)]
i40e: clear mac filter count on reset

Orabug: 24568124

When a VF is reset, it gets a new VSI, so all of its MAC filters go
away. Correctly set the number of filters to 0 when freeing VF
resources. This corrects a problem with failure to add filters when the
VF driver is reloaded.

Change-ID: I2acbecf734287b67473bb225293e14b5096acbef
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>
(cherry picked from commit 13fd3f9cc3def8b276c7913ae4acbfa2653cb198)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Reorder logic for coalescing RS bits
Alexander Duyck [Tue, 11 Oct 2016 22:26:54 +0000 (15:26 -0700)]
i40e: Reorder logic for coalescing RS bits

Orabug: 24568124

This patch reorders the logic at the end of i40e_tx_map to address the
fact that the logic was rather convoluted and much larger than it needed
to be.

In order to try and coalesce the code paths I have updated some of the
comments and repurposed some of the variables in order to reduce
unnecessary overhead.

This patch does the following:
1.  Quit tracking skb->xmit_more with a flag, just max out packet_stride
2.  Drop tail_bump and do_rs and instead just use desc_count and td_cmd
3.  Pull comments from ixgbe that make need for wmb() more explicit.

Change-ID: Ic7da85ec75043c634e87fef958109789bcc6317c
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>
(cherry picked from commit 1dc8b538795fcf92161cc056ceebb852cf375b17)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/net/ethernet/intel/i40e/i40e_txrx.c
drivers/net/ethernet/intel/i40evf/i40e_txrx.c

Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Add common function for finding VSI by type
Alexander Duyck [Tue, 11 Oct 2016 22:26:53 +0000 (15:26 -0700)]
i40e: Add common function for finding VSI by type

Orabug: 24568124

This patch adds a common method for finding a VSI by type.  The main
motivation for doing this is that the Flow Director path actually had two
ways of handling this, one stopped on first match and one did not.  This
patch makes it so that all callers of this function will get the same
approach for finding a VSI.

Change-ID: Ibf25de8acd8466582520694424aa87da66965fbd
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
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>
(cherry picked from commit 4b8164467b854fbeb7ecbb14cf53b6be9113ef03)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: avoid an extra msleep while
Jacob Keller [Wed, 5 Oct 2016 16:30:45 +0000 (09:30 -0700)]
i40evf: avoid an extra msleep while

Orabug: 24568124

Remove the second call to msleep outside the loop, and move the msleep
within the loop as the first step. This guarantees that a single loop
will wait the minimum time first, and then after the reset finishes we
no longer need an extra msleep.

Change-ID: Ib2086f0a142402b614f67846bc091754203a0b9a
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>
(cherry picked from commit 7d3f04af69bed2db87d6a72d100e182f773e54b7)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: replace PTP Rx timestamp hang logic
Jacob Keller [Wed, 5 Oct 2016 16:30:44 +0000 (09:30 -0700)]
i40e: replace PTP Rx timestamp hang logic

Orabug: 24568124

The current Rx timestamp hang logic is not very robust because it does
not notice a register is hung until all four timestamps have been
latched and we wait a full 5 seconds. Replace this logic with a newer Rx
hang detection based on storing the jiffies when we first notice
a receive timestamp event. We store each register's time separately,
along with a flag indicating if it is currently latched. Upon first
transitioning to latch, we will update the latch_events[i] jiffies
value. This indicates the time we first noticed this event. The watchdog
routine will simply check that the either the flag has been cleared, or
we have passed at least one second. In this case, it is able to clear
the Rx timestamp register under the assumption that it was for a dropped
frame. The benefit if this strategy is that we should be able to
detect and clear out stalled RXTIME_H registers before we exhaust the
supply of 4, and avoid complete stall of Rx timestamp events.

Change-ID: Id55458c0cd7a5dd0c951ff2b8ac0b2509364131f
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>
(cherry picked from commit 124905012db8bdeebf5a7d1ddc841eaadda84a75)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: use a mutex instead of spinlock in PTP user entry points
Jacob Keller [Wed, 5 Oct 2016 16:30:43 +0000 (09:30 -0700)]
i40e: use a mutex instead of spinlock in PTP user entry points

Orabug: 24568124

We need a locking mechanism to protect the hardware SYSTIME register
which is split over 2 values, and has internal hardware latching. We
can't allow multiple accesses at the same time. However....

The spinlock_t is overkill here, especially use of spin_lock_irqsave,
since every PTP access will halt hardirqs. Notice that the only places
which need the SYSTIME value are user context and are capable of sleeping.
Thus, it is safe to use a mutex here instead of the spinlock.

Change-ID: I971761a89b58c6aad953590162e85a327fbba232
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>
(cherry picked from commit 195512629c956286265dcfeeea2028c42ee0c483)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: correct check for reading TSYNINDX from the receive descriptor
Jacob Keller [Wed, 5 Oct 2016 16:30:42 +0000 (09:30 -0700)]
i40e: correct check for reading TSYNINDX from the receive descriptor

Orabug: 24568124

When hardware has taken a timestamp for a received packet, it indicates
which RXTIME register the timestamp was placed in by some bits in the
receive descriptor. It uses 3 bits, one to indicate if the descriptor
index is valid (ie: there was a timestamp) and 2 bits to indicate which
of the 4 registers to read. However, the driver currently does not check
the TSYNVALID bit and only checks the index. It assumes a zero index
means no timestamp, and a non zero index means a timestamp occurred.
While this appears to be true, it prevents ever reading a timestamp in
RXTIME[0], and causes the first timestamp the device captures to be
ignored.

Fix this by using the TSYNVALID bit correctly as the true indicator of
whether the packet has an associated timestamp.

Also rename the variable rsyn to tsyn as this is more descriptive and
matches the register names.

Change-ID: I4437e8f3a3df2c2ddb458b0fb61420f3dafc4c12
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>
(cherry picked from commit 144ed1763003c6a88a4b788cc5da1d8a1ddf061f)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: remove duplicate add/delete adminq command code for filters
Jacob Keller [Wed, 5 Oct 2016 16:30:41 +0000 (09:30 -0700)]
i40e: remove duplicate add/delete adminq command code for filters

Orabug: 24568124

We duplicate some code around adding and deleting filters using the
adminq interface. This is prone to errors in case there are bugs. Use
functions which extract the logic to their own portion so that we don't
duplicate it twice in code.

Change-ID: I60d68aeb887976787dec00b23ab386a106e61465
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>
(cherry picked from commit 0093631966aad046ddf21e157a43765c295e16a3)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: avoid looping to check whether we're in VLAN mode
Jacob Keller [Wed, 5 Oct 2016 16:30:40 +0000 (09:30 -0700)]
i40e: avoid looping to check whether we're in VLAN mode

Orabug: 24568124

We determine that a VSI is in vlan_mode whenever it has any filters
with a VLAN other than -1 (I40E_VLAN_ALL). The previous method of doing
so was to perform a loop whenever we needed the check. However, we can
notice that only place where filters are added (i40e_add_filter) can
change the condition from false to true, and the only place we can
return to false is in i40e_vsi_sync_filters_subtask. Thus, we can remove
the loop and use a boolean directly.

Doing this avoids looping over filters repeatedly especially while we're
already inside a loop over all the filters. This should reduce the
latency of filter operations throughout the driver.

Change-ID: Iafde08df588da2a2ea666997d05e11fad8edc338
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>
(cherry picked from commit cbebb85f306f6023ebaa26ca66380571b4b680bf)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix MAC filters when removing VLANs
Alan Brady [Wed, 5 Oct 2016 16:30:39 +0000 (09:30 -0700)]
i40e: fix MAC filters when removing VLANs

Orabug: 24568124

Currently there exists a bug where adding at least one VLAN and then
removing all VLANs leaves the mac filters for the VSI with an incorrect
value for 'vid' which indicates the mac filter's VLAN status.

The current implementation for handling the removal of VLANs is wrong
for a couple reasons. The first is that when i40e_vsi_kill_vlan
iterates through the MAC filters, it fails to account for the MAC filter
status; i.e. it's not accommodating for filters that are about to be
deleted. The second problem is that MAC filters can be deleted in other
places (specifically i40e_set_rx_mode). Thus if it occurs that all the
VLAN MAC filters get deleted we need to switch out of VLAN mode, but the
code path through i40e_vsi_kill_vlan has already been executed and we're
now stuck in VLAN mode.

This patch fixes the issue by removing the check from i40e_vsi_kill_vlan
and puts the check instead in i40e_sync_vsi_filters where we're
guaranteed to see all filter deletions and can properly detect when we
need to switch out of VLAN mode.

Change-ID: Ib38fe6034b356eee9a0e20b8a9eeed5ff2debcd9
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>
(cherry picked from commit 84f5ca6cf4ea1d91fa9ee858ff95211127b0166b)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: properly cleanup on allocation failure in i40e_sync_vsi_filters
Jacob Keller [Wed, 5 Oct 2016 16:30:38 +0000 (09:30 -0700)]
i40e: properly cleanup on allocation failure in i40e_sync_vsi_filters

Orabug: 24568124

Currently, we fail to correctly restore filters on the temporary add
list when we fail to allocate memory either for deletion or addition.
Replace calls to "goto out;" with calls to a new location that correctly
handles memory allocation failures.

Note that it is safe for us to call i40e_undo_filter_entries on the
tmp_del_list even after we've deleted filters because at this point it
will be empty, so we don't need to separate the logic for add and
delete failure.

Change-Id: Iee107fd219c6e03e2fd9645c2debf8e8384a8521
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>
(cherry picked from commit 4a2ce27bb5f291c38d8e49ef16899828289e4d3d)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: store MAC/VLAN filters in a hash with the MAC Address as key
Jacob Keller [Wed, 5 Oct 2016 16:30:37 +0000 (09:30 -0700)]
i40e: store MAC/VLAN filters in a hash with the MAC Address as key

Orabug: 24568124

Replace the mac_filter_list with a static size hash table of 8bits. The
primary advantage of this is a decrease in latency of operations related
to searching for specific MAC filters, including .set_rx_mode. Using
a linked list resulted in several locations which were O(n^2). Using
a hash table should give us latency growth closer to O(n*log(n)).

Change-ID: I5330bd04053b880e670210933e35830b95948ebb
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
(cherry picked from commit 278e7d0b9d6864a9749b9473a273892aa1528621)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: implement __i40e_del_filter and use where applicable
Jacob Keller [Wed, 5 Oct 2016 16:30:36 +0000 (09:30 -0700)]
i40e: implement __i40e_del_filter and use where applicable

Orabug: 24568124

When inside a loop where we call i40e_del_filter we use an O(n^2)
pattern where i40e_del_filter calls i40e_find_filter for us. We can
avoid this O(n^2) logic by factoring a function, __i40e_del_filter() out
from the i40e_del_filter code. This allows us to re-use the delete logic
where appropriate without having to search for the filter twice.

This new function benefits several functions including i40e_vsi_add_vlan,
i40e_vsi_kill_vlan, i40e_del_mac_vlan_all, and i40e_vsi_release.

Change-ID: I75fabe0f53bf73f56b80d342e5fdcfcc28f4d3eb
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>
(cherry picked from commit 290d255719af42ae4baaf49165a69b9ad47f2049)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: When searching all MAC/VLAN filters, ignore removed filters
Jacob Keller [Wed, 5 Oct 2016 16:30:35 +0000 (09:30 -0700)]
i40e: When searching all MAC/VLAN filters, ignore removed filters

Orabug: 24568124

When adding new MAC address filters, the driver determines if it should
behave in VLAN mode (where all MAC addresses get assigned to every
existing VLAN) or in non-VLAN mode where MAC addresses get assigned the
VLAN_ANY identifier. Under some circumstances it is possible that a VLAN
has been marked for removal (such that all filters of that VLAN are set
to I40E_FILTER_REMOVE), and a subsequent call to i40e_put_mac_in_vlan
may occur prior to the driver subtask that syncs filters to the
hardware.

In this case, we may add filters to the new removed VLAN, even though it
should have been removed. This is most obvious when first adding a new
VLAN. We will delete all filters which are in I40E_VLAN_ANY (-1) and
then re-add them as in VLAN 0 (untagged). Then before we sync filters,
we will add new MAC address filter, which will be added to every VLAN
that exists. Unfortunately, this will include I40E_VLAN_ANY, so we will
end up incorrectly adding filters to the -1 VLAN. This can be fixed by
simply skipping all filters which are marked for removal.

A similar check is not necessary in i40e_del_mac_all_vlan, since we are
deleting, and any filter which we find already marked for removal would
simply be deleted again, which doesn't cause any issues.

Change-Id: I7962154013ce02fe950584690aeeb3ed853d0086
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>
(cherry picked from commit 57b341d66684e380cae332eadcc210e177a9f289)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: refactor i40e_put_mac_in_vlan to avoid changing f->vlan
Jacob Keller [Wed, 5 Oct 2016 16:30:34 +0000 (09:30 -0700)]
i40e: refactor i40e_put_mac_in_vlan to avoid changing f->vlan

Orabug: 24568124

When a PVID has been assigned to a VSI, the function
i40e_put_mac_in_vlan arbitrarily modifies all filters
to have the same VLAN. This is obviously incorrect
because it could be modifying active filters without
putting them into the NEW state. The correct method
is to remove then re-add filters which is already done
in the code where we assign the PVID.

Fix this issue and a few other minor nits at the same
time. First, when we have a PVID don't even bother
looping and simply add the filter with the PVID immediately.

In the case of the loop, we now can remove several checks.
We also don't need to use i40e_find_filter first before
calling i40e_add_filter, since i40e_add_filter implicitly
does a lookup already.

Finally, update the return semantics of this function so
that on failure to add a filter it returns NULL, but on
success, it returns the last filter added. Otherwise,
we're just returning the last filter in the list. An
alternative fix might be to return 0 or an error code,
but this is pretty invasive to every call site.

Change-ID: I2325dfd843aec76d89fb0d7cb0e7c4f290a34840
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5feb3d7b0c0a66c8537ca8a79d8f80f54783e73f)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: move i40e_put_mac_in_vlan and i40e_del_mac_all_vlan
Jacob Keller [Wed, 5 Oct 2016 16:30:33 +0000 (09:30 -0700)]
i40e: move i40e_put_mac_in_vlan and i40e_del_mac_all_vlan

Orabug: 24568124

A future patch will be modifying these functions and making a call to
a static function which currently is defined after these functions. Move
them in a separate patch to ease review and ensure the moved code is
correct.

Change-ID: I2ca7fd4e10c0c07ed2291db1ea41bf5987fc6474
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>
(cherry picked from commit 35ec2ff37c5a4897e75d408828adac737b17d2bf)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: make use of __dev_uc_sync and __dev_mc_sync
Jacob Keller [Wed, 5 Oct 2016 16:30:32 +0000 (09:30 -0700)]
i40e: make use of __dev_uc_sync and __dev_mc_sync

Orabug: 24568124

The kernel provides __dev_uc_sync and __dev_mc_sync in order for drivers
which need individual notification of add and delete for each filter.
These functions allow us to vastly simplify our .set_rx_mode handler. We
need to implement two functions for sync and unsync which add and remove
filters respectively.

This change avoids a very complex and inefficient algorithm which
resulted in an abnormal latency for the .set_rx_mode NDO operation. The
resulting code after this change is more readable, more efficient, and
less code.

Due to the callback signature used by these functions we also must
update several other functions to take a const u8 * pointer.

Change-Id: I2ca7fd4e10c0c07ed2291db1ea41bf5987fc6474
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>
(cherry picked from commit 6622f5cdbaf3786314d76969d2aab132b36ba2e8)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: drop is_vf and is_netdev fields in struct i40e_mac_filter
Jacob Keller [Wed, 5 Oct 2016 16:30:31 +0000 (09:30 -0700)]
i40e: drop is_vf and is_netdev fields in struct i40e_mac_filter

Orabug: 24568124

Originally the is_vf and is_netdev fields were added in order to
distinguish between VF and netdev filters in a single VSI. However, it
can be noted that we use separate VSI for SRIOV VFs and for netdev VSI.
Thus, since a single VSI should only ever have one type of filter, we
can simply remove the checks and remove the typing.

In a similar fashion, we can note that the only remaining way to get
multiple filters of a single type is through a debug command that was
added to debugfs. This command is useless in practice, and results in
causing bugs if we keep counter tracking but lose the is_vf and
is_netdev protections as desired above.

Since the only time we'd actually have a counter value besides 0 and
1 is through use of this debugfs hook, we can remove this unnecessary
command, and the entire counter logic it required.

We vastly simplify mac filters by removing

(a) the distinction between VF and netdev filters
(b) counting logic
(c) the ability to add and remove filters bypassing the stack via debugfs

Change-ID: Idf916dd2a1159b1188ddbab5bef6b85ea6bf27d9
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 1bc87e807a6510eb33402258ec1df9bf22b6ff1f)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Add missing \n to end of dev_err message
Colin Ian King [Tue, 4 Oct 2016 11:20:16 +0000 (12:20 +0100)]
i40e: Add missing \n to end of dev_err message

Orabug: 24568124

Trival fix, dev_err message is missing a \n, so add it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ff00f3a9670f97203b33ac00eeca81d75768919e)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Clean up handling of msglevel flags and debug parameter
Alexander Duyck [Fri, 30 Sep 2016 12:21:46 +0000 (08:21 -0400)]
i40e: Clean up handling of msglevel flags and debug parameter

Orabug: 24568124

So the i40e driver had a really convoluted configuration for how to handle
the debug flags contained in msg_level.  Part of the issue is that the
driver has its own 32 bit mask that it was using to track a separate set of
debug features.  From what I can tell it was trying to use the upper 4 bits
to determine if the value was meant to represent a bit-mask or the numeric
value provided by debug level.

What this patch does is clean this up by compressing those 4 bits into bit
31, as a result we just have to perform a check against the value being
negative to determine if we are looking at a debug level (positive), or a
debug mask (negative).  The debug level will populate the msg_level, and
the debug mask will populate the debug_mask in the hardware struct.

I added similar logic for ethtool.  If the value being provided has bit 31
set we assume the value being provided is a debug mask, otherwise we assume
it is a msg_enable mask.  For displaying we only provide the msg_enable,
and if debug_mask is in use we will print it to the dmesg log.

Lastly I removed the debugfs interface.  It is redundant with what we
already have in ethtool and really doesn't belong anyway.

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>
(cherry picked from commit 5d4ca23e58f2db7c14b76070f31295244b6edb7b)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix bit logic error in failure case
David Ertman [Fri, 30 Sep 2016 08:36:21 +0000 (01:36 -0700)]
i40e: Fix bit logic error in failure case

Orabug: 24568124

Patch a036244c0686 "i40e: Fix kernel panic on enable/disable LLDP"
introduced an error in bit logic.

Originally this bit manipulation was meant to clear two bits to indicate
that DCB was not enabled or capable. An "&" was incorrectly used instead
of an "|" bit operator to combine the two bitmasks into one.  This also
created a static checker error since the resultant code was a no-op.

This patch fixes the error by using the correct bit-wise operator.

Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c17ef430b9fd5f58074f5cdc0128d06a5ae92304)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf: Changed version from 1.6.19 to 1.6.21
Bimmy Pujari [Tue, 27 Sep 2016 18:28:54 +0000 (11:28 -0700)]
i40e/i40evf: Changed version from 1.6.19 to 1.6.21

Orabug: 24568124

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>
(cherry picked from commit cf465fe750412335b7a3c75263bd795aecef4fef)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Removal of workaround for simple MAC address filter deletion
Filip Sadowski [Tue, 27 Sep 2016 18:28:53 +0000 (11:28 -0700)]
i40e: Removal of workaround for simple MAC address filter deletion

Orabug: 24568124

This is code refactoring. This patch removes the workaround which deleted
a default MAC filter added by the firmware when the interface was brought
up. This filter caused frames to pass disregarding the VLAN tagging.
It used to be automatically applied after reset in pre-SRA FW versions.
This workaround is not needed in production NICs and hence can be removed.

Change-ID: I129fe1aae1f17b5a224c9b29a996d916aa1be1ec
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>
(cherry picked from commit 53cb6e9e8949b13f63db0bc96f8fcc249763acfb)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix for long link down notification time
Carolyn Wyborny [Tue, 27 Sep 2016 18:28:52 +0000 (11:28 -0700)]
i40e: Fix for long link down notification time

Orabug: 24568124

This patch fixes a problem where it could take a very
long time (>100 msec) to print the link down notification.
This problem is fixed by changing how often we update link
info from fw, when link is down. Without this patch, it can
take over 100msec to notify user link is down.

Change-ID: Ib876eb30834c7080792becd13ee093b9cbb35d78
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>
(cherry picked from commit ab425cb7ffdb024a45b0b3bcbf58d52ead3c347c)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Drop redundant Rx descriptor processing code
Alexander Duyck [Tue, 27 Sep 2016 18:28:50 +0000 (11:28 -0700)]
i40e: Drop redundant Rx descriptor processing code

Orabug: 24568124

This patch cleans up several pieces of redundant code in the Rx clean-up
paths.

The first bit is that hdr_addr and the status_err_len portions of the Rx
descriptor represent the same value.  As such there is no point in setting
them to 0 before setting them to 0.  I'm dropping the second spot where we
are updating the value to 0 so that we only have 1 write for this value
instead of 2.

The second piece is the checking for the DD bit in the packet.  We only
need to check for a non-zero value for the status_err_len because if the
device is done with the descriptor it will have written something back and
the DD is just one piece of it.  In addition I have moved the reading of
the Rx descriptor bits related to rx_ptype down so that they are actually
below the dma_rmb() call so that we are guaranteed that we don't have any
funky 64b on 32b calls causing any ordering issues.

Change-ID: I256e44a025d3c64a7224aaaec37c852bfcb1871b
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>
(cherry picked from commit 99dad8b34c687cb8c4975fbabced76db35f88c14)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix confusing dmesg info for ethtool -L option
Lihong Yang [Tue, 27 Sep 2016 18:28:48 +0000 (11:28 -0700)]
i40e: fix confusing dmesg info for ethtool -L option

Orabug: 24568124

Ethtool -L option with the combined parameter is for changing the number of
multi-purpose channels of the specified network device. The pre-set maximum
for the combined channels is cpu dependent. Currently, for an i40e device,
when the user sets a value between 64 and the maximum that the cpu can
support for the combined parameter, the i40e driver displays the confusing
info in dmesg to only show 64 as the RSS count regardless of what the
accepted user input is as long as it is larger than 64.

This patch fixes the message in the i40e driver when the user uses
ethtool -L to change the number of the combined channels to consistently
display the user requested value if it is valid and accepted by ethtool.

Change-ID: Ia80a68bc844b779a49e0f76e7d3dcc915032d9af
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>
(cherry picked from commit 128150576f85b2745d849aba43980683a6267e50)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Make struct i40e_stats const
Joe Perches [Tue, 27 Sep 2016 03:17:01 +0000 (20:17 -0700)]
i40e: Make struct i40e_stats const

Orabug: 24568124

Move some data to text

$ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o*
   text    data     bss     dec     hex filename
  25012       0      32   25044    61d4 drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new
  22868    2120      32   25020    61bc drivers/net/ethernet/intel/i40e/i40e_ethtool.o.old

Signed-off-by: Joe Perches <joe@perches.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit fe180a5e275adc7430ada9e4881dcca5ea1a8037)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf: Changed version from 1.6.16 to 1.6.19
Bimmy Pujari [Wed, 14 Sep 2016 23:24:39 +0000 (16:24 -0700)]
i40e/i40evf: Changed version from 1.6.16 to 1.6.19

Orabug: 24568124

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>
(cherry picked from commit 4adbb642eaf53dfe2ea0a4170d8df95d115c12ac)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf: fix interrupt affinity bug
Alan Brady [Wed, 14 Sep 2016 23:24:38 +0000 (16:24 -0700)]
i40e/i40evf: fix interrupt affinity bug

Orabug: 24568124

There exists a bug in which a 'perfect storm' can occur and cause
interrupts to fail to be correctly affinitized. This causes unexpected
behavior and has a substantial impact on performance when it happens.

The bug occurs if there is heavy traffic, any number of CPUs that have
an i40e interrupt are pegged at 100%, and the interrupt afffinity for
those CPUs is changed.  Instead of moving to the new CPU, the interrupt
continues to be polled while there is heavy traffic.

The bug is most readily realized as the driver is first brought up and
all interrupts start on CPU0. If there is heavy traffic and the
interrupt starts polling before the interrupt is affinitized, the
interrupt will be stuck on CPU0 until traffic stops. The bug, however,
can also be wrought out more simply by affinitizing all the interrupts
to a single CPU and then attempting to move any of those interrupts off
while there is heavy traffic.

This patch fixes the bug by registering for update notifications from
the kernel when the interrupt affinity changes. When that fires, we
cache the intended affinity mask. Then, while polling, if the cpu is
pegged at 100% and we failed to clean the rings, we check to make sure
we have the correct affinity and stop polling if we're firing on the
wrong CPU.  When the kernel successfully moves the interrupt, it will
start polling on the correct CPU. The performance impact is minimal
since the only time this section gets executed is when performance is
already compromised by the CPU.

Change-ID: I4410a880159b9dba1f8297aa72bef36dca34e830
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>
(cherry picked from commit 96db776a368263bcce9f7eb12e878b0aef1a1974)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/net/ethernet/intel/i40e/i40e_txrx.c
drivers/net/ethernet/intel/i40evf/i40e_txrx.c

Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: group base mode VF offload flags
Preethi Banala [Wed, 14 Sep 2016 23:24:37 +0000 (16:24 -0700)]
i40e: group base mode VF offload flags

Orabug: 24568124

Group together the minimum set of offload capabilities that are always
supported by VF in base mode. This define would be used by PF to make
sure VF in base mode gets minimum of base capabilities .

Change-ID: Id5e8f22ba169c8f0a38d22fc36b2cb531c02582c
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>
(cherry picked from commit 6d6fd1be2a1052cbe5b04c3678b30925a9344ac7)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: reopen client after reset
Mitch Williams [Wed, 14 Sep 2016 23:24:36 +0000 (16:24 -0700)]
i40e: reopen client after reset

Orabug: 24568124

Allow the client interface to reopen existing clients if they were
closed. This allows clients to recover from reset, which is essential
for supporting VF RDMA. In one instance, the driver was not clearing the
open bit when the client was closed. Add the code to clear this bit so
that the state is accurate and the driver will not attempt to reopen
already-open clients. Remove the ref_cnt variable; it was just getting
in the way and was not being used consistently.

Change-ID: Ic71af4553b096963ac0c56a997f887c9a4ed162d
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 7be96322a57a3612ea7640e6ff56030a7350fd7f)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Drop code for unsupported flow types
Alexander Duyck [Wed, 14 Sep 2016 23:24:35 +0000 (16:24 -0700)]
i40e: Drop code for unsupported flow types

Orabug: 24568124

We cannot currently support SCTP in the hardware, and IPV4_FLOW is not used
anywhere by the software so we can go through and drop the functionality
related to these two flow types.

In addition we cannot support masking based on the protocol value so if the
user is expecting a value other than TCP or UDP we should simply return an
error rather then trying to allocate a filter for a rule that will only
partially match what the user requested.

Change-ID: I10d52bb97d8104d76255fe244551814ff9531a63
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>
(cherry picked from commit e1da71ca88170d1a6232951294b44dc0c824e464)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Remove unused function i40e_vsi_lookup
Alexander Duyck [Wed, 14 Sep 2016 23:24:34 +0000 (16:24 -0700)]
i40e: Remove unused function i40e_vsi_lookup

Orabug: 24568124

The function is not used so there is no need to carry it forward.  I have
plans to add a slightly different function that can be inlined to handle
the same kind of functionality.

Change-ID: Ie2dfcb189dc75e5fbc156bac23003e3b4210ae0f
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>
(cherry picked from commit dc7621205a93a00a898c193cf985c4c1a65a47d6)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Bit test mask correction
Filip Sadowski [Wed, 14 Sep 2016 23:24:33 +0000 (16:24 -0700)]
i40e: Bit test mask correction

Orabug: 24568124

Incorrect bit mask was used for testing "get link status" response.
Instead of I40E_AQ_LSE_ENABLE (which is actually 0x03) it most probably
should be I40E_AQ_LSE_IS_ENABLED (which is defined as 0x01).

Change-ID: Ia199142906720507f847de3a33a25c61a9781b2f
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>
(cherry picked from commit 7ed3573223dd6bf36b1bd35c8e5e3d0cd4f6f690)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Rewrite Flow Director busy wait loop
Alexander Duyck [Wed, 14 Sep 2016 23:24:32 +0000 (16:24 -0700)]
i40e: Rewrite Flow Director busy wait loop

Orabug: 24568124

We can reorder the busy wait loop at the start of the Flow Director
transmit function to reduce the overall code size while still retaining the
same functionality.  As such I am taking advantage of the opportunity to do
so.

Change-ID: I34c403ca001953c6ac9816e65d5305e73d869026
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>
(cherry picked from commit ed245406da1409437f9d2c4e7c69112fb255964c)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix client interaction
Carolyn Wyborny [Wed, 14 Sep 2016 23:24:31 +0000 (16:24 -0700)]
i40e: Fix client interaction

Orabug: 24568124

This patch fixes a problem in the client interface that
was causing random stack traces in RDMA driver load and
unload tests.  This patch fixes the problem by checking
for an existing client before trying to open it.  Without
this patch, there is a timing related null pointer deref.

Change-ID: Ib73d30671a27f6f9770dd53b3e5292b88d6b62da
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c73d2e8462d0bb1d47b0e8f6a33d97ab9a154824)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: disable MSI-X interrupts if we cannot reserve enough vectors
Guilherme G Piccoli [Thu, 22 Sep 2016 13:03:58 +0000 (10:03 -0300)]
i40e: disable MSI-X interrupts if we cannot reserve enough vectors

Orabug: 24568124

If we fail on allocating enough MSI-X interrupts, we should disable
them since they were previously enabled in this point of code.

Not disabling them can lead to WARN_ON() being triggered and subsequent
failure in enabling MSI as a fallback; the below message was shown without
this patch while we played with interrupt allocation in i40e driver:

[ 21.461346] sysfs: cannot create duplicate filename '/devices/pci0007:00/0007:00:00.0/0007:01:00.3/msi_irqs'
[ 21.461459] ------------[ cut here ]------------
[ 21.461514] WARNING: CPU: 64 PID: 1155 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x88/0xc0

Also, we noticed that without this patch, if we modprobe the module without
enough MSI-X interrupts (triggering the above warning), unload the module
and re-load it again, we got a crash on the system.

Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 4c95aa5d8fc34be18fcab01b1c6251c8c2b61520)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix configure TCs after initial DCB disable
David Ertman [Tue, 20 Sep 2016 14:10:50 +0000 (07:10 -0700)]
i40e: Fix configure TCs after initial DCB disable

Orabug: 24568124

in commit a036244c068612a43fa8c0f33a0eb4daa4d8dba0 a fix
was put into place to avoid a kernel panic when a non-
supported traffic class configuration was put into place
and then lldp was enabled/disabled on the link partner
switch.  This fix caused it to be necessary to
unload/reload the driver to reenable DCB once a supported
TC config was in place.

The root cause of the original panic was that the function
i40e_pf_get_default_tc was allowing for a default TC other
than TC 0, and only TC 0 is supported as a default.

This patch removes the get_default_tc function and replaces
it with a #define since there is only one TC supported as
a default.

Change-Id: I448371974e946386d0a7718d73668b450b7c72ef
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Tested-by: Ronald Bynoe <ronald.j.bynoe@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ea6acb7ef78960e4b6f1cd8c4162a5e490e83dcd)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: avoid NULL pointer dereference and recursive errors on early PCI error
Guilherme G Piccoli [Mon, 3 Oct 2016 07:31:12 +0000 (00:31 -0700)]
i40e: avoid NULL pointer dereference and recursive errors on early PCI error

Orabug: 24568124

Although rare, it's possible to hit PCI error early on device
probe, meaning possibly some structs are not entirely initialized,
and some might even be completely uninitialized, leading to NULL
pointer dereference.

The i40e driver currently presents a "bad" behavior if device hits
such early PCI error: firstly, the struct i40e_pf might not be
attached to pci_dev yet, leading to a NULL pointer dereference on
access to pf->state.

Even checking if the struct is NULL and avoiding the access in that
case isn't enough, since the driver cannot recover from PCI error
that early; in our experiments we saw multiple failures on kernel
log, like:

  [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15
  [549.664] i40e: probe of 0007:01:00.1 failed with error -15
  [...]
  [871.644] i40e 0007:01:00.1: The driver for the device stopped because the
  device firmware failed to init. Try updating your NVM image.
  [871.644] i40e: probe of 0007:01:00.1 failed with error -32
  [...]
  [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored

Between the first probe failure (error -15) and the second (error -32)
another PCI error happened due to the first bad probe. Also, driver
started to flood console with those ARQ event messages.

This patch will prevent these issues by allowing error recovery
mechanism to remove the failed device from the system instead of
trying to recover from early PCI errors during device probe.

CC: <stable@vger.kernel.org>
Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
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>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix sideband flow director vector allocation
Stefan Assmann [Mon, 19 Sep 2016 11:37:51 +0000 (13:37 +0200)]
i40e: fix sideband flow director vector allocation

Orabug: 24568124

Currently if the MSI-X vector limit is reached the sideband flow
director gets disabled. A bit too early to make that decision, as
vectors may get re-distributed. So move the check further back.

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>
(cherry picked from commit abd97a94ba913d121a920d5541aba1e568be6972)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix MSI-X vector redistribution if hw limit is reached
Stefan Assmann [Mon, 19 Sep 2016 11:37:50 +0000 (13:37 +0200)]
i40e: fix MSI-X vector redistribution if hw limit is reached

Orabug: 24568124

The driver allocates 1 vector per CPU thread and the current hardware
limit for vectors is 129 per PF. On systems with 128 or more threads
this currently means all vectors are used by the PF leaving no room for
additional features like VMDq, iWARP, etc...
The code that should redistribute the vectors in this case is broken and
never triggers. Fixed the code so that it actually triggers if the
hardware limit is reached and adjust the number of queue pairs
accordingly.
Also the number of initially requested iWARP vectors was not properly
saved when the vector limit was reached, and therefore always zero.

Comparison with debug statement.
Before:
i40e 0000:2d:00.0: VMDq disabled, not enough MSI-X vectors
i40e 0000:2d:00.0: IWARP disabled, not enough MSI-X vectors
i40e 00.0 MSI-X vector distribution: PF 128, VMDq 0, FDSB 0, iWARP 0
After:
i40e 0000:2d:00.0: MSI-X vector limit reached, attempting to redistribute vectors
i40e 00.0 MSI-X vector distribution: PF 78, VMDq 8, FDSB 0, iWARP 42

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>
(cherry picked from commit 4ce20abc645fc1822e86d9845a8562347e877b36)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: check if vectors are already depleted when doing VMDq allocation
Stefan Assmann [Mon, 19 Sep 2016 11:37:49 +0000 (13:37 +0200)]
i40e: check if vectors are already depleted when doing VMDq allocation

Orabug: 24568124

During MSI-X vector allocation for VMDq, a check for "no vectors left"
was missing, add it. This prevents more vectors to be allocated than
available.

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>
(cherry picked from commit 9ca57e97a75780a7f9b8e93e83ab1e36dbfd9846)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: support queue-specific settings for interrupt moderation
Jacob Keller [Mon, 12 Sep 2016 21:18:44 +0000 (14:18 -0700)]
i40evf: support queue-specific settings for interrupt moderation

Orabug: 24568124

In commit a75e8005d506f3 ("i40e: queue-specific settings for interrupt
moderation") the i40e driver gained support for setting interrupt
moderation values per queue. This patch adds support for this feature
to the i40evf driver as well. In addition, a few changes are made to
the i40e implementation to add function header documentation comments,
as well.

This behaves in a similar fashion to the implementation in i40e. Thus,
requesting the moderation value when no queue is provided will report
queue 0 value, while setting the value without a queue will set all
queues at once.

Change-ID: I1f310a57c8e6c84a8524c178d44d1b7a6d3a848e
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>
(cherry picked from commit 65e87c0398f542d5bd51cfd8a29b9dfd246b6a1c)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Conflicts:
drivers/net/ethernet/intel/i40e/i40e_ethtool.c

Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: don't configure zero-size RSS table
Mitch Williams [Mon, 12 Sep 2016 21:18:43 +0000 (14:18 -0700)]
i40e: don't configure zero-size RSS table

Orabug: 24568124

In some rare cases, we might get a VSI with no queues. In this case, we
cannot configure RSS on this VSI as it will try to divide by zero when
configuring the lookup table.

Change-ID: I6ae173a7dd3481a081e079eb10eb80275de2adb0
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>
(cherry picked from commit a4fa59cc5bb028ebb8048e8dcb6f92b2a1ea07f6)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Strip out debugfs hook for Flow Director filter programming
Alexander Duyck [Mon, 12 Sep 2016 21:18:42 +0000 (14:18 -0700)]
i40e: Strip out debugfs hook for Flow Director filter programming

Orabug: 24568124

This  interface was only ever meant for debug only. Since it is not
supposed to be here we are removing it.

Change-ID: Id771a1e5e7d3e2b4b7f56591b61fb48c921e1d04
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>
(cherry picked from commit 1eb846ac90b956e52f4269d80f13cfbe1df6850b)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Split Flow Director descriptor config into separate function
Alexander Duyck [Mon, 12 Sep 2016 21:18:41 +0000 (14:18 -0700)]
i40e: Split Flow Director descriptor config into separate function

Orabug: 24568124

In an effort to improve code readability I am splitting the Flow Director
filter configuration out into a separate function like we have done for the
standard xmit path.  The general idea is to provide a single block of code
that translates the flow specification into a proper Flow Director
descriptor.

Change-ID: Id355ad8030c4e6c72c57504fa09de60c976a8ffe
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>
(cherry picked from commit 5e02f2837349b399e48fd2a5e5149c9ee9c27cdd)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf: Add txring_txq function to match fm10k and ixgbe
Alexander Duyck [Mon, 12 Sep 2016 21:18:40 +0000 (14:18 -0700)]
i40e/i40evf: Add txring_txq function to match fm10k and ixgbe

Orabug: 24568124

This patch adds a txring_txq function which allows us to convert a
i40e_ring/i40evf_ring to a netdev_tx_queue structure.  This way we
can avoid having to make a multi-line function call for all the spots
that need access to this.

Change-ID: Ic063b71d8b92ea406d2c32e798c8e2b02809d65b
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>
(cherry picked from commit e486bdfd7c491e997f29fcdf6a4216861ab1d06a)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix Flow Director raw_buf cleanup
Alexander Duyck [Mon, 12 Sep 2016 21:18:39 +0000 (14:18 -0700)]
i40e: Fix Flow Director raw_buf cleanup

Orabug: 24568124

The Tx cleanup flow was incorrectly assuming it could check for the flow
director bits after it had unmapped the buffer.  However in this case it
results in us trying to free a raw_buf as though it is an sk_buff.

To fix this I am moving up the flag test for the FD_SB bit so that when
find a non-NULL skb or raw_buf value we then check the flag and use the
appropriate call to free the buffer.

Change-ID: I6284034ba1ea87c9922e56f6eb3181f7f09bddde
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>
(cherry picked from commit 64bfd68eaecdce7b86e179fe39662340c8aed20d)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: enable adaptive interrupt throttling
Mitch Williams [Mon, 12 Sep 2016 21:18:38 +0000 (14:18 -0700)]
i40evf: enable adaptive interrupt throttling

Orabug: 24568124

All of the code to support adaptive interrupt throttling is already in
the interrupt handler, it just needs to be enabled. Fill out the data
structures properly to make it happen. Single-flow traffic tests may
show slightly lower throughput, but interrupts per second will drop by
about 75%.

Change-ID: I9cd7d42c025b906bf1bb85c6aeb6112684aa6471
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>
(cherry picked from commit f19a973f46e85d4394cadb90fa7717f7ec98197a)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Increase minimum number of allocated VSI
Akeem Abodunrin [Mon, 12 Sep 2016 21:18:37 +0000 (14:18 -0700)]
i40e: Increase minimum number of allocated VSI

Orabug: 24568124

This patch increases minimum number of allocated VSIs, so as to resolve
failure adding VSI for VF when 64-VFs assigned to a PF. The driver
supports up to 128 VFs per device, users can decide to enable up to
64-VFs on a single PF, especially 2 X 40 devices. In that scenario, with
VMDq co-existence, there would be starvation of VSIs - with this patch,
supported features would have enough VSIs for configuration now.

Change-ID: If084f4cd823667af8fe7fdc11489c705b32039d5
Signed-off-by: Akeem Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 7ac4b5c6fd351be8f849f687e290ca9724acfd33)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf: Changed version to 1.6.16
Bimmy Pujari [Wed, 7 Sep 2016 01:05:12 +0000 (18:05 -0700)]
i40e/i40evf: Changed version to 1.6.16

Orabug: 24568124

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>
(cherry picked from commit fa90efa59dabbaac24f1ad2e6535e6daa2845257)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: removing unreachable code
Henry Tieman [Wed, 7 Sep 2016 01:05:11 +0000 (18:05 -0700)]
i40e: removing unreachable code

Orabug: 24568124

The return value from i40e_shutdown_adminq() is always 0
(I40E_SUCCESS). So, the test for non-0 will never be true. Cleanup
by removing the test and debug print statement.

Change-ID: Ie51e8e37515c3e3a6a9ff26fa951d0e5e24343c1
Signed-off-by: Henry Tieman <henry.w.tieman@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ac9c5c6d8c17fa105878442ac663f0e9abe3cff5)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: check conflicting ntuple/sideband rules when re-enabling ATR
Jacob Keller [Wed, 7 Sep 2016 01:05:10 +0000 (18:05 -0700)]
i40e: check conflicting ntuple/sideband rules when re-enabling ATR

Orabug: 24568124

In i40e_fdir_check_and_reenable(), the driver performs some checks to
determine whether it is safe to re-enable FD Sideband and FD ATR
support. The current check will only determine if there is available
space in the flow director table. However, this ignores the fact that
ATR should be disabled when there are TCP/IPv4 sideband rules in effect.
Add the missing check, and update the info message printed when
I40E_DEBUG_FD is enabled.

Change-ID: Ibb9c63e5be95d63c53a498fdd5dbf69f54a00e08
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>
(cherry picked from commit a3417d287fb02e7bd24c6b1068fe6f9b52a259a6)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: cleanup ATR auto_disable_flags use
Jacob Keller [Wed, 7 Sep 2016 01:05:09 +0000 (18:05 -0700)]
i40e: cleanup ATR auto_disable_flags use

Orabug: 24568124

Some locations that disable ATR accidentally used the "full" disable by
disabling the flag in the standard flags field. This incorrectly forces
ATR off permanently instead of temporarily disabling it. In addition,
some code locations accidentally set the ATR flag enabled when they only
meant to clear the auto_disable_flags. This results in ignoring the
user's ethtool private flag settings.

Additionally, when disabling ATR via ethtool, we did not perform a flush
of the FD table. This results in the previously assigned ATR rules still
functioning which was not expected.

Cleanup all these areas so that automatic disable uses only the
auto_disable_flag. Fix the flush code so that we can trigger a flush
even when we've disabled ATR and SB support, as otherwise the flush
doesn't work. Fix ethtool setting to actually request a flush. Fix
NETIF_F_NTUPLE flag to only clear the auto_disable setting and not
enable the full feature.

Change-ID: Ib2486111f8031bd16943e9308757b276305c03b5
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>
(cherry picked from commit 234dc4e67611c11bb3990abced26cb75b8ef262a)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: add encap csum VF offload flag
Preethi Banala [Wed, 7 Sep 2016 01:05:08 +0000 (18:05 -0700)]
i40e: add encap csum VF offload flag

Orabug: 24568124

Add ENCAP_CSUM offload negotiation flag. Currently VF assumes checksum
offload for encapsulated packets is supported by default. Going forward,
this feature needs to be negotiated with PF before advertising to the
stack. Hence, we need a flag to control it.
This is in regards to prepping up for VF base mode functionality support.

Change-ID: Iaab1f25cc0abda5f2fbe3309092640f0e77d163e
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>
(cherry picked from commit 2199254cb50a650934ef2d1c531ec6fdc0a826c5)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix deleting mac filters
Alan Brady [Wed, 7 Sep 2016 01:05:07 +0000 (18:05 -0700)]
i40e: fix deleting mac filters

Orabug: 24568124

There exists a bug in which deleting a mac filter does not actually
occur.  The driver reports that the filter has been deleted with no
error.  The problem occurs because the wrong cmd_flag is passed to the
firmware when deleting the filter.  The firmware reports an error back
to the driver but it is expressly ignored.

This fixes the bug by using the correct flag when deleting a filter.
Without this patch, deleted filters remain in firmware and function as
if they had not been deleted.

Change-ID: I5f22b874f3b83f457702f18f0d5602ca21ac40c3
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>
(cherry picked from commit a6cb91464b5b09c0ff749e4b01048f93ce450275)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Remove 100 Mbps SGMII support for X722
Harshitha Ramamurthy [Wed, 7 Sep 2016 01:05:06 +0000 (18:05 -0700)]
i40e: Remove 100 Mbps SGMII support for X722

Orabug: 24568124

This patch fixes the problem where driver shows 100 Mbps as a supported speed,
and allows it to be configured for advertising on X722 devices. This patch
fixes the problem by not setting the 100 Mbps SGMII flag for X722 devices.

Without this patch, the user incorrectly thinks that 100 Mbps is supported
and hence might try to advertise it on X722 devices when it is actually not
a supported speed.

Change-ID: I8c3d7c4251a9402d98994ed29749b7b895a0f205
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>
(cherry picked from commit f2c7c1d09832ef0d6499a9e1a958c3ddc686f723)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: remove unnecessary error checking against i40e_shutdown_adminq
Lihong Yang [Wed, 7 Sep 2016 01:05:05 +0000 (18:05 -0700)]
i40evf: remove unnecessary error checking against i40e_shutdown_adminq

Orabug: 24568124

The i40e_shutdown_adminq function never returns failure. There is no need to
check the non-0 return value. Clean up the unnecessary error checking and
warning against it.

Change-ID: Ibb616f09cfb93bd1a872ebf3241a15fb8354b31b
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>
(cherry picked from commit 903e68323bb62cc8ca30c5a7a41d962f92c27b97)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Limit TX descriptor count in cases where frag size is greater than 16K
Alexander Duyck [Wed, 7 Sep 2016 01:05:04 +0000 (18:05 -0700)]
i40e: Limit TX descriptor count in cases where frag size is greater than 16K

Orabug: 24568124

The i40e driver was incorrectly assuming that we would always be pulling
no more than 1 descriptor from each fragment.  It is in fact possible for
us to end up with the case where 2 descriptors worth of data may be pulled
when a frame is larger than one of the pieces generated when aligning the
payload to either 4K or pieces smaller than 16K.

To adjust for this we just need to make certain to test all the way to the
end of the fragments as it is possible for us to span 2 descriptors in the
block before us so we need to guarantee that even the last 6 descriptors
have enough data to fill a full frame.

Change-ID: Ic2ecb4d6b745f447d334e66c14002152f50e2f99
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>
(cherry picked from commit 841493a3f64395b60554afbcaa17f4350f90e764)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: remove unnecessary error checking against i40evf_up_complete
Bimmy Pujari [Wed, 7 Sep 2016 01:05:03 +0000 (18:05 -0700)]
i40evf: remove unnecessary error checking against i40evf_up_complete

Orabug: 24568124

Function i40evf_up_complete() always returns success. Changed this to a
void type and removed the code that checks the return status and prints
an error message.

Change-ID: I8c400f174786b9c855f679e470f35af292fb50ad
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>
(cherry picked from commit cb130a0b41d2a825fa48d7dfc964f08da9ccbb96)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: Fix link state event handling
Sridhar Samudrala [Thu, 1 Sep 2016 20:27:27 +0000 (22:27 +0200)]
i40evf: Fix link state event handling

Orabug: 24568124

Currently disabling the link state from PF via
ip link set enp5s0f0 vf 0 state disable
doesn't disable the CARRIER on the VF.

This patch updates the carrier and starts/stops the tx queues based on the
link state notification from PF.

  PF: enp5s0f0, VF: enp5s2
  #modprobe i40e
  #echo 2 > /sys/class/net/enp5s0f0/device/sriov_numvfs
  #ip link set enp5s2 up
  #ip -d link show enp5s2
  175: enp5s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
      link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64
  #ip link set enp5s0f0 vf 0 state disable
  #ip -d link show enp5s0f0
  171: enp5s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
      link/ether 68:05:ca:2e:72:68 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 72 numrxqueues 72 portid 6805ca2e7268
      vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state disable, trust off
      vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto, trust off
  #ip -d link show enp5s2
  175: enp5s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
       link/ether ea:4d:60:bc:6f:85 brd ff:ff:ff:ff:ff:ff promiscuity 0 addrgenmode eui64 numtxqueues 16 numrxqueues 16

Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3f341acc1c65b800ced567174c683cda12dfb17d)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: avoid potential null pointer dereference when assigning len
Colin Ian King [Sun, 28 Aug 2016 17:41:01 +0000 (18:41 +0100)]
i40e: avoid potential null pointer dereference when assigning len

Orabug: 24568124

There is a sanitcy check for desc being null in the first line of
function i40evf_debug_aq.  However, before that, aq_desc is cast from
desc, and aq_desc is being dereferenced on the assignment of len, so
this could be a potential null pointer deference.  Fix this by moving
the initialization of len to the code block where len is being used
and hence at this point we know it is OK to dereference aq_desc.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ff918912e1b8ba4e743d1f0b06ced1d01969e17c)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix for extra byte swap in tunnel setup
Carolyn Wyborny [Wed, 24 Aug 2016 18:33:51 +0000 (11:33 -0700)]
i40e: Fix for extra byte swap in tunnel setup

Orabug: 24568124

This patch fixes an issue where we were byte swapping the port
parameter, then byte swapping it again in function execution.
Obviously, that's unnecessary, so take it out of the function calls.
Without this patch, the udp based tunnel configuration would
not be correct.

Change-ID: I788d83c5bd5732170f1a81dbfa0b1ac3ca8ea5b7
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>
(cherry picked from commit b3f5c7bc88bab134e9649e42d30be15e3775f00d)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix to check for NULL
Carolyn Wyborny [Wed, 24 Aug 2016 18:33:50 +0000 (11:33 -0700)]
i40e: Fix to check for NULL

Orabug: 24568124

This patch fixes an issue in the virt channel code, where a return
from i40e_find_vsi_from_id was not checked for NULL when applicable.
Without this patch, there is a risk for panic and static analysis
tools complain. This patch fixes the problem by adding the check
and adding an additional input check for similar reasons.

Change-ID: I7e9be88eb7a3addb50eadc451c8336d9e06f5394
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>
(cherry picked from commit d4a0658d813ec72965a52f04f07258a4018ccb17)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: return correct opcode to VF
Mitch Williams [Wed, 24 Aug 2016 18:33:49 +0000 (11:33 -0700)]
i40e: return correct opcode to VF

Orabug: 24568124

This conditional is backward, so the driver responds back to the VF with
the wrong opcode. Do the old switcheroo to fix this.

Change-ID: I384035b0fef8a3881c176de4b4672009b3400b25
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>
(cherry picked from commit 8d9d927f4ab8d87fee91d9aa8bdcdf19a1787ce0)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix "dump port" command when NPAR enabled
Alan Brady [Wed, 24 Aug 2016 18:33:47 +0000 (11:33 -0700)]
i40e: fix "dump port" command when NPAR enabled

Orabug: 24568124

When using the debugfs to issue the "dump port" command
with NPAR enabled, the firmware reports back with invalid argument.

The issue occurs because the pf->mac_seid was used to perform the query.
This is fine when NPAR is disabled because the switch ID == pf->mac_seid,
however this is not the case when NPAR is enabled.  This fix instead
goes through the VSI to determine the correct ID to use in either case.

Change-ID: I0cd67913a7f2c4a2962e06d39e32e7447cc55b6a
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>
(cherry picked from commit a01c7f6709925919e2e3c6c190a92692f63f74e4)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix setting user defined RSS hash key
Alan Brady [Wed, 24 Aug 2016 18:33:46 +0000 (11:33 -0700)]
i40e: fix setting user defined RSS hash key

Orabug: 24568124

Previously, when using ethtool to change the RSS hash key, ethtool would
report back saying the old key was still being used and no error was
reported.  It was unclear whether it was being reported incorrectly or
being set incorrectly.  Debugging revealed 'i40e_set_rxfh()' returned
zero immediately instead of setting the key because a user defined
indirection table is not supplied when changing the hash key.

This fix instead changes it such that if an indirection table is not
supplied, then a default one is created and the hash key is now
correctly set.

Change-ID: Iddb621897ecf208650272b7ee46702cad7b69a71
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>
(cherry picked from commit f15823510246444052b35f148c7ae627842b0e05)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix kernel panic on enable/disable LLDP
Dave Ertman [Tue, 30 Aug 2016 00:38:26 +0000 (17:38 -0700)]
i40e: Fix kernel panic on enable/disable LLDP

Orabug: 24568124

If DCB is configured on the link partner switch with an
unsupported traffic class configuration (e.g. non-contiguous TCs),
the driver is flagging DCB as disabled.  But, for future DCB
LLDPDUs, the driver was checking if the interface was DCB capable
instead of enabled.  This was causing a kernel panic when LLDP
was enabled/disabled on the link partner switch.

This patch corrects the situation by having the LLDP event handler
check the correct flag in the pf structure.  It also cleans up the
setting and clearing of the enabled flag for other checks.

Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a036244c068612a43fa8c0f33a0eb4daa4d8dba0)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Change some init flow for the client
Anjali Singhai Jain [Thu, 25 Aug 2016 00:51:53 +0000 (17:51 -0700)]
i40e: Change some init flow for the client

Orabug: 24568124

This change makes a common flow for Client instance open during init
and reset path. The Client subtask can handle both the cases instead of
making a separate notify_client_of_open call.
Also it may fix a bug during reset where the service task was leaking
some memory and causing issues.

Change-Id: I7232a32fd52b82e863abb54266fa83122f80a0cd
Signed-off-by: Anjali Singhai Jain <anjali.singhai@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>
(cherry picked from commit f38ff2ee7727994685494bcc4d7c274b35b5418a)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: Open RDMA Client after reset
Avinash Dayanand [Wed, 17 Aug 2016 23:04:08 +0000 (16:04 -0700)]
i40evf: Open RDMA Client after reset

Orabug: 24568124

RDMA client is closed during the PF reset and needs to be opened again.
Setting the flag so that RDMA client is opened in watchdog() function.

Change-ID: I507b1e4cbd05528cdff68fd360ef3dcac8901263
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>
(cherry picked from commit bf3a178c8a064d38f2570e6b8e4de2db07cd7083)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf: Fix indentation
Jeff Kirsher [Sat, 20 Aug 2016 04:47:41 +0000 (21:47 -0700)]
i40e/i40evf: Fix indentation

Orabug: 24568124

Several defines and code comments were indented with spaces instead
of tabs, correct the issue to make indentation consistent.

Change-ID: I0dc6bbb990ec4a9e856acc9ec526d876181f092c
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
(cherry picked from commit c57c99597376c2a223b1ff472f614211ade44e76)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Correcting mutex usage in client code
Avinash Dayanand [Wed, 17 Aug 2016 23:04:06 +0000 (16:04 -0700)]
i40e: Correcting mutex usage in client code

Orabug: 24568124

Correcting the mutex usage, in client_subtask(), mutex_unlock has
to be called just before client_del_instance() since this function opens
and later closes the same mutex again.
Similarly in client_is_registered removing the mutex since it closes
the mutex twice.

This is a patch suggested by RDMA team.

Change-ID: Icce519c266e4221b8a2a72a15ba5bf01750e5852
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>
(cherry picked from commit 0d8ab54a4119880bb9cb4680da1f5e9068d0d333)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Remove XSTRINGIFY macro definitions and uses
Joe Perches [Wed, 17 Aug 2016 10:37:31 +0000 (03:37 -0700)]
i40e: Remove XSTRINGIFY macro definitions and uses

Orabug: 24568124

Use __stringify instead.

Signed-off-by: Joe Perches <joe@perches.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 35f5034f8e4bb4bce0c95a2aea2c719afbf8201f)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Initialize pointer in client_release function
Harshitha Ramamurthy [Mon, 15 Aug 2016 21:17:19 +0000 (14:17 -0700)]
i40e: Initialize pointer in client_release function

Orabug: 24568124

The function i40e_client_release has a print statement that uses an
adapter pointer which is not initialized if a previous if statement
is not true. Hence, intialize it in the right place.

Change-ID: I1afdaa2c46771ac42be56edcc41bb56b455b06c8
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>
(cherry picked from commit 682d11d7001e61710b282df51a51250a57514772)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Check client is open before calling client ops
Catherine Sullivan [Mon, 15 Aug 2016 21:17:18 +0000 (14:17 -0700)]
i40e: Check client is open before calling client ops

Orabug: 24568124

We were having a race between the completion of the client open and
calls to the client ops so don't call a client op unless we are sure the
client is open.

Testing Hints: Load IWARP driver and make sure it works as expected.

Change-Id: I741f4f2aa4fcbfdad3e40dabbbb1b005856c396b
Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 91cdca4faa3e4085b37cc084b15955bb20ca2e31)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: use matching format identifiers
Heinrich Schuchardt [Wed, 10 Aug 2016 23:07:22 +0000 (01:07 +0200)]
i40e: use matching format identifiers

Orabug: 24568124

i is defined as int but output as %u several times.
Adjust the format identifiers.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit fbcfac34167328f9a063e6abd03298afabfe228b)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Add support for HMC resource and profile for X722
Carolyn Wyborny [Thu, 4 Aug 2016 18:37:05 +0000 (11:37 -0700)]
i40e: Add support for HMC resource and profile for X722

Orabug: 24568124

This patch adds support for HMC resource and profile cmds for X722
firmware.

Change-ID: Icc332101f38ab15d1bfa167823100eb4f6822f7e
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>
(cherry picked from commit 7d94906bee43384be85b767d41718463f3630869)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix byte ordering in ARP NS code for X722
Carolyn Wyborny [Thu, 4 Aug 2016 18:37:04 +0000 (11:37 -0700)]
i40e: Fix byte ordering in ARP NS code for X722

Orabug: 24568124

This patch fixes byte ordering problems found when enabling this feature
support. Without this patch, the feature will not work correctly. This
patch fixes the definitions to have the correct byte order.

Change-ID: Ic7489fbcbe2195df7be62ff5e359201b827cefe6
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>
(cherry picked from commit b7eeef495f62412bc8b0a9f8c94710653e4cdd28)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: refactor tail_bump check
Carolyn Wyborny [Thu, 4 Aug 2016 18:37:03 +0000 (11:37 -0700)]
i40e: refactor tail_bump check

Orabug: 24568124

This patch refactors tail bump check.

Change-ID: Ide0e19171d67d90cb2b06b8dcd4fa791ae120160
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>
(cherry picked from commit ffeac83685facb6f0829b898d567056eae8097f8)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: report link speed
Mitch Williams [Thu, 4 Aug 2016 18:37:02 +0000 (11:37 -0700)]
i40evf: report link speed

Orabug: 24568124

The PF driver tells us the link speed, so do something with that
information. Add link speed to log messages, and report speed through
ethtool.

Change-Id: I279dc9540cc5203376406050a3e8d67e128d5882
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>
(cherry picked from commit fe458e50711b8a3dc773a6aa1f80b477991c8bbe)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: use alloc_workqueue instead of create_singlethread_workqueue
Jacob Keller [Thu, 4 Aug 2016 18:37:01 +0000 (11:37 -0700)]
i40e: use alloc_workqueue instead of create_singlethread_workqueue

Orabug: 24568124

Replace calls to create_singlethread_workqueue instead with alloc_workqueue
as is style with other Intel drivers. This provides more control over
workqueue creation, and allows explicit setting of the desired mode of
operation. It also makes it more obvious that driver name constant is
passed to a format "%s".

Change-ID: I6192b44caf5140336cd54c5b350d51c73b541fdb
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>
(cherry picked from commit 6992a6c9c435c10253a229ce61852f5305fae646)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: use configured RSS key and lookup table in i40e_vsi_config_rss
Jacob Keller [Tue, 19 Jul 2016 23:23:31 +0000 (16:23 -0700)]
i40e: use configured RSS key and lookup table in i40e_vsi_config_rss

Orabug: 24568124

A previous refactor added support to store user configuration for VSIs,
so that extra VSIs such as for VMDq can use this information when
configuring. Unfortunately the i40e_vsi_config_rss function was missed
in this refactor, and the values were being ignored. Fix this by
checking for the fields and using those instead of always using the
default 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>
(cherry picked from commit 552b996256241198a08005a91a206b402ac234f6)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix broken i40e_config_rss_aq function
Jacob Keller [Tue, 19 Jul 2016 23:23:30 +0000 (16:23 -0700)]
i40e: fix broken i40e_config_rss_aq function

Orabug: 24568124

X722 hardware requires using the admin queue to configure RSS. This
function was previously re-written in commit e69ff813af35 ("i40e: rework
the functions to configure RSS with similar parameters").
However, the previous refactor did not work correctly for a few reasons

(a) it does not check whether seed is NULL before using it, resulting in
a NULL pointer dereference

[  402.954721] BUG: unable to handle kernel NULL pointer dereference at           (null)
[  402.955568] IP: [<ffffffffa0090ccf>] i40e_config_rss_aq.constprop.65+0x2f/0x1c0 [i40e]
[  402.956402] PGD ad610067 PUD accc0067 PMD 0
[  402.957235] Oops: 0000 [#1] SMP
[  402.958064] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_filter ebtable_
broute bridge stp llc ebtable_nat ebtables ip6table_mangle ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv
6 ip6table_security ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_nat nf_conntrack_ipv4_ nf_defrag_ipv4_ nf_nat_ip
v4_ nf_nat nf_conntrack iptable_security intel_rapl i86_kg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_clMl crc32_
pclMl ghash_clMlni_intel iTCO_wdt iTCO_vendor_support shpchp sb_edac dcdbas pcspkr joydev ipmi_devintf wmi edac_core ipmi_ssif
 acpi_ad acpi_ower_meter ipmi_si ipmi_msghandler mei_me nfsd lpc_ich mei ioatdma tpm_tis auth_rpcgss tpm nfs_acl lockd grace s
unrpc ifs nngag200 i2c_algo_bit drm_kms_helper ttm drm iigbe bnx2x i40e dca mdio ptp pps_core libcrc32c fjes crc32c_intel
[  402.965563] CPU: 22 PID: 2461 Conm: ethtool Not tainted 4.6.0-rc7_1.2-ABNidQ+ #20
[  402.966719] Hardware name: Dell Inc. PowerEdge R720/0C4Y3R, BIOS 2.5.2 01/28/2015
[  402.967862] task: ffff880219b51dc0 ti: ffff8800b3408000 task.ti: ffff8800b3408000
[  402.969046] RIP: 0010:[<ffffffffa0090ccf>]  [<ffffffffa0090ccf>] i40e_config_rss_aq.constprop.65+0x2f/0x1c0 [i40e]
[  402.970339] RSP: 0018:ffff8800b340ba90  EFLAGS: 00010246
[  402.971616] RAX: 0000000000000000 RBX: ffff88042ec14000 RCX: 0000000000000200
[  402.972961] RDX: ffff880428eb9200 RSI: 0000000000000000 RDI: ffff88042ec14000
[  402.974312] RBP: ffff8800b340baf8 R08: ffff880237ada8f0 R09: ffff880428eb9200
[  402.975709] R10: ffff880428eb9200 R11: 0000000000000000 R12: ffff88042ec2e000
[  402.977104] R13: ffff88042ec2e000 R14: ffff88042ec14000 R15: ffff88022ea00800
[  402.978541] FS:  00007f84fd054700(0000) GS:ffff880237ac0000(0000) knlGS:0000000000000000
[  402.980003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  402.981508] CR2: 0000000000000000 CR3: 000000003289e000 CR4: 00000000000406e0
[  402.983028] Stack:
[  402.984578]  0000000002000200 0000000000000000 ffff88023ffeda68 ffff88023ffef000
[  402.986187]  0000000000000268 ffff8800b340bbf8 ffff88023ffedd80 0000000088ce4f1d
[  402.987844]  ffff88042ec14000 ffff88022ea00800 ffff88042ec2e000 ffff88042ec14000
[  402.989509] Call Trace:
[  402.991200]  [<ffffffffa009636f>] i40e_config_rss+0x11f/0x1c0 [i40e]
[  402.992924]  [<ffffffffa00a1ae0>] i40e_set_rifh+0ic0/0x130 [i40e]
[  402.994684]  [<ffffffff816d54b7>] ethtool_set_rifh+0x1f7/0x300
[  402.996446]  [<ffffffff8136d02b>] ? cred_has_capability+0io6b/0x100
[  402.998203]  [<ffffffff8136d102>] ? selinux_capable+0x12/0x20
[  402.999968]  [<ffffffff8136277b>] ? security_capable+0x4b/0x70
[  403.001707]  [<ffffffff816d6da3>] dev_ethtool+0x1423/0x2290
[  403.003461]  [<ffffffff816eab41>] dev_ioctl+0x191/0io630
[  403.005186]  [<ffffffff811cf80a>] ? lru_cache_add+0x3a/0i80
[  403.006942]  [<ffffffff817f2a8e>] ? _raw_spin_unlock+0ie/0x20
[  403.008691]  [<ffffffff816adb95>] sock_do_ioctl+0x45/0i50
[  403.010421]  [<ffffffff816ae229>] sock_ioctl+0x209/0x2d0
[  403.012173]  [<ffffffff81262194>] do_vfs_ioctl+0u4/0io6c0
[  403.013911]  [<ffffffff81262829>] SyS_ioctl+0x79/0x90
[  403.015710]  [<ffffffff817f2e72>] entry_SYSCALL_64_fastpath+0x1a/0u4
[  403.017500] Code: 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 40 4c 8b a7 e0 05 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 <48> 8b 06 41 0f b7 bc 24 f2 0f 00 00 48 89 45 9c 48 8b 46 08 48
[  403.021454] RIP  [<ffffffffa0090ccf>] i40e_config_rss_aq.constprop.65+0x2f/0x1c0 [i40e]
[  403.023395]  RSP <ffff8800b340ba90>
[  403.025271] CR2: 0000000000000000
[  403.027169] ---[ end trace 64561b528cf61cf0 ]---

(b) it does not even bother to use the passed in *lut parameter which
defines the requested lookup table. Instead it uses its own round robin
table.

Fix these issues by re-writing it to be similar to i40e_config_rss_reg
and i40e_get_rss_aq.

Fixes: e69ff813af35 ("i40e: rework the functions to configure RSS with similar parameters", 2015-10-21)
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>
(cherry picked from commit 776b2e15f8af7900409456292efd45af6de97172)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: move i40e_vsi_config_rss below i40e_get_rss_aq
Jacob Keller [Tue, 19 Jul 2016 23:23:29 +0000 (16:23 -0700)]
i40e: move i40e_vsi_config_rss below i40e_get_rss_aq

Orabug: 24568124

Move this function below the two functions related to configuring RSS
via the admin queue. This helps co-locate the two functions, and made it
easier to spot a bug in the first i40e_config_rss_aq function as
compared to the i40e_get_rss_aq function.

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>
(cherry picked from commit 0582b964ece795fa2810eace82bf9b2233403d65)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: remove a stray unlock
Dan Carpenter [Wed, 3 Aug 2016 19:01:07 +0000 (22:01 +0300)]
i40e: remove a stray unlock

Orabug: 24568124

We shifted the locking around a bit but forgot to delete this unlock so
now it can unlock twice.

Fixes: cd3be169a5ff ('i40e: Move the mutex lock in i40e_client_unregister')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit be0cb0a66a1d426f7cd9b170c008725044ae147a)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e/i40evf-Bump version from 1.6.11 to 1.6.12
Bimmy Pujari [Wed, 27 Jul 2016 19:02:41 +0000 (12:02 -0700)]
i40e/i40evf-Bump version from 1.6.11 to 1.6.12

Orabug: 24568124

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>
(cherry picked from commit 93e6fa2c34bef36fc64be44e501c6ba729671d8d)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Allow RSS Hash set with less than four parameters
Carolyn Wyborny [Wed, 27 Jul 2016 19:02:40 +0000 (12:02 -0700)]
i40e: Allow RSS Hash set with less than four parameters

Orabug: 24568124

This patch implements a feature change which allows using ethtool to set
RSS hash opts using less than four parameters if desired.

Change-ID: I0fbb91255d81e997c456697c21ac39cc9754821b
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Signed-off-by: Kiran Patil <kiran.patil@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit eb0dd6e4a3b3df5a733476e417ed3230d0adfc4e)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix memory leak
Mitch Williams [Wed, 27 Jul 2016 19:02:39 +0000 (12:02 -0700)]
i40e: fix memory leak

Orabug: 24568124

When we allocate memory, we must free it. It's simple courtesy.

Change-ID: Id007294096fb53344f1a8b9a0f78eddf9853c5d6
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>
(cherry picked from commit b7d2cd951f7147f979d9e82773246416dcef2e3e)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: fix lookup table when RSS disabled/enabled
Alan Brady [Wed, 27 Jul 2016 19:02:38 +0000 (12:02 -0700)]
i40e: fix lookup table when RSS disabled/enabled

Orabug: 24568124

This patch fixes the bug which causes RSS to continue to work
after being disabled.  After disabling RSS, traffic would continue
to be assigned to different queues instead of falling back to a
single queue. Without this patch, attempting to disable RSS would
not work as expected. This patch fixes the bug by clearing the
lookup table used by RSS such that all traffic is assigned to a
single queue.  This patch also addresses the issue of reinstating
 the lookup table should RSS then be re-enabled.

Change-ID: Ib20c7c6a7e9f1f772bb787370f8a8c664796b141
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>
(cherry picked from commit d8ec98646483a9e1c0c9f511236ce8b933deed17)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Don't notify client of VF reset during VF creation
Avinash Dayanand [Wed, 27 Jul 2016 19:02:37 +0000 (12:02 -0700)]
i40e: Don't notify client of VF reset during VF creation

Orabug: 24568124

VF goes through reset path during VF creation which happens to also
have notification of VF reset to client. Adding conditional check to
avoid wrongly notifying VF reset during VF creation.

Also changing the call order of VF enable, calling it after VF creation
rather than before.

Change-ID: I96eabd99deae746a2f0fc465194c886f196178ce
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>
(cherry picked from commit 6a23449a2356d7d41addb0c89f512dfef455beb2)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Force register writes to mitigate sync issues with iwarp VF driver
Avinash Dayanand [Wed, 27 Jul 2016 19:02:36 +0000 (12:02 -0700)]
i40e: Force register writes to mitigate sync issues with iwarp VF driver

Orabug: 24568124

This patch is a fix for the bug i.e. unable to create iwarp device
in VF. This is a sync issue and the iwarp device open is called even
before the PCI register writes are done.

Forcing the PCI register writes to happen just before it exits the
function.

Change-ID: I60c6a2c709da89e845f2764cc50ce8b7373c8c44
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>
(cherry picked from commit 70df973b5eb48b19ba29105ecfecb3e50efe3c6d)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: don't allow reduction of channels below active FD rules
Jacob Keller [Wed, 27 Jul 2016 19:02:35 +0000 (12:02 -0700)]
i40e: don't allow reduction of channels below active FD rules

Orabug: 24568124

If a driver is unable to maintain all current user supplied settings
from ethtool (or other sources), it is not ok for a user request to
succeed and silently trample over previous configuration.

To that end, if you change the number of channels, it must not be
allowed to reduce the number of channels (queues) below the current
flow director filter rules targets. In this case, return -EINVAL when
a request to reduce the number of channels would do so. In addition
log a warning to the kernel buffer explaining why we failed, and report
the rules which prevent us from lowering the number of channels.

Change-ID: If41464d63d7aab11cedf09e4f3aa1a69e21ffd88
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>
(cherry picked from commit 59826d9becf76d949d09173e2c41e4049f4ca763)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40e: Fix static analysis tool warning
Dave Ertman [Wed, 27 Jul 2016 19:02:34 +0000 (12:02 -0700)]
i40e: Fix static analysis tool warning

Orabug: 24568124

This patch fixes a problem where a static analysis tool generates
a warning for "INVARIANT_CONDITION: Expression 'enabled_tc' used
in the condition always yields the same result."

Without this patch, the driver will not pass the static analysis
tool checks without generating warnings.

This patch fixes the problem by eliminating the irrelevant check
and redundant assignment for the value of enabled_tc.

Change-ID: Ia7d44cb050f507df7de333e96369d322e08bf408
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 52a08caa0cd5b9b37020c96f2b59ce1160def8fa)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>
8 years agoi40evf: add missing rtnl_lock() around i40evf_set_interrupt_capability
Jacob Keller [Wed, 27 Jul 2016 19:02:33 +0000 (12:02 -0700)]
i40evf: add missing rtnl_lock() around i40evf_set_interrupt_capability

Orabug: 24568124

The function calls netif_set_real_num_(tx|rx)_queues, both of which
should be done only under rntl lock. Unfortunately the
i40evf_init_task did not hold the rtnl_lock as necessary. This patch
adds the locking needed.

Change-ID: Ib72a21c3ce22b71a226b16f9bbe0f5f8cc3e849b
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>
(cherry picked from commit 62fe2a865e6ddc92f574bafacf8376613d8c08f2)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
Signed-off-by: Dhaval Giani <dhaval.giani@oracle.com>