Alexander Duyck [Tue, 3 Nov 2015 01:09:29 +0000 (17:09 -0800)]
ixgbe: Return error on failure to allocate mac_table
BugLink: http://bugs.launchpad.net/bugs/1536473
Add a check to make certain mac_table was actually allocated and is not
NULL. If it is NULL return -ENOMEM and allow the probe routine to fail
rather then causing a NULL pointer dereference further down the line.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 530fd82a9fea5bba8e044bdf6fdf2ddc495e3807) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 19 Nov 2015 21:56:30 +0000 (13:56 -0800)]
ixgbevf: Handle extended IPv6 headers in Tx path
BugLink: http://bugs.launchpad.net/bugs/1536473
Check for and handle IPv6 extended headers so that Tx checksum
offload can be done. Also use skb_checksum_help for unexpected
cases. Thanks to Tom Herbert for noticing these problems. Thanks
to Alexander Duyck for seeing how to coalesce the error handling
into one location.
Reported-by: Tom Herbert <tom@herbertland.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d34a614adfb16a560ddb6759d532eb32b6651eae) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 5 Nov 2015 19:02:14 +0000 (11:02 -0800)]
ixgbe: Always turn PHY power on when requested
BugLink: http://bugs.launchpad.net/bugs/1536473
Instead of inhibiting PHY power control when manageability is
present, only inhibit turning PHY power off when manageability
is present. Consequently, PHY power will always be turned on when
requested. Without this patch, some systems with X540 or X550
devices in some conditions will never get link.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3c2f2b77a917488b56b2676b99adb5d3c07d6e68) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Wed, 18 Nov 2015 17:21:28 +0000 (09:21 -0800)]
ixgbe: Handle extended IPv6 headers in Tx path
BugLink: http://bugs.launchpad.net/bugs/1536473
Check for and handle IPv6 extended headers so that Tx checksum
offload can be done. Also use skb_checksum_help for unexpected
cases. Thanks to Tom Herbert for noticing these problems. Thanks
to Alexander Duyck for recognizing problems with the first version
of this patch and recognizing how to coalesce error conditions
into a single location.
Reported-by: Tom Herbert <tom@herbertland.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 36a92d7190e68e9387347695fe4625eb2c9e7e1c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Fri, 30 Oct 2015 22:29:34 +0000 (15:29 -0700)]
ixgbe: Save VF info and take references
BugLink: http://bugs.launchpad.net/bugs/1536473
Save VF device pointers and take references to speed accesses used
to monitor the device behavior to avoid slot resets. The saved
information avoids lock contention during the search used to access
each of the VFs.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 988d13073fe122f0b6a2b80b5f2aa1b0717f9edb) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Tue, 27 Oct 2015 20:23:23 +0000 (13:23 -0700)]
ixgbe: Wait for master disable to be set
BugLink: http://bugs.launchpad.net/bugs/1536473
According to the datasheets, the driver should wait for the master
disable bit to read as being set before checking the status
register for master disable.
Reported-by: Dan Streetman <dan.streetman@canonical.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 48b44612738793252c97c548f3d0bd56543d5273) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Tue, 27 Oct 2015 20:23:14 +0000 (13:23 -0700)]
ixgbe: Correct spec violations by waiting after reset
BugLink: http://bugs.launchpad.net/bugs/1536473
The ixgbe driver was violating the specification in the datasheet
by not waiting 1ms before checking for the reset bit clearing. This
is called out for devices supported by ixgbe, so implement the
required delay.
Reported-by: Dan Streetman <dan.streetman@canonical.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit efff2e027758fd5cc739d500397f729591f32a94) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Tue, 27 Oct 2015 16:58:07 +0000 (09:58 -0700)]
ixgbe: Update PTP to support X550EM_x devices
BugLink: http://bugs.launchpad.net/bugs/1536473
The X550EM_x devices handle clocking differently, so update the
PTP implementation to accommodate them. This involves significant
changes to ixgbe's PTP code to accommodate the new range of
behaviors including things like non-power-of-2 clock wrapping.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a9763f3cb54c7f1c6a47962c814935654476d09f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Previously the code limited us to 16 unicast entries, however this was
shared between MACVLAN which wasn't limited and the FDB code which was. So
instead of treating the FDB code as a second class citizen I have updated
it so that it has access to just as many entries as the MACVLAN filters.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2f9be1665585a3757a00a6d1b8201d0ede937a34) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Thu, 22 Oct 2015 23:26:36 +0000 (16:26 -0700)]
ixgbe: Use __dev_uc_sync and __dev_uc_unsync for unicast addresses
BugLink: http://bugs.launchpad.net/bugs/1536473
This change replaces the ixgbe_write_uc_addr_list call in ixgbe_set_rx_mode
with a call to __dev_uc_sync instead. This works much better with the MAC
addr list code that was already in place and solves an issue in which you
couldn't remove an FDB address without having to reset the port.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 0f079d22834ac0529413bdee5b5aa52485942162) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Thu, 22 Oct 2015 23:26:30 +0000 (16:26 -0700)]
ixgbe: Refactor MAC address configuration code
BugLink: http://bugs.launchpad.net/bugs/1536473
In the process of tracking down a memory leak when adding/removing FDB
entries I had to go through the MAC address configuration code for ixgbe.
In the process of doing so I found a number of issues that impacted
readability and performance. This change updates the code in general to
clean it up so it becomes clear what each step is doing. From what I can
tell there a couple of bugs cleaned up in this code.
First is the fact that the MAC addresses were being double counted for the
PF. As a result once entries up to 63 had been used you could no longer
add additional filters.
A simple test case for this:
for i in `seq 0 96`
do
ip link add link ens8 name mv$i type macvlan
ip link set dev mv$i up
done
When things are working correctly RAL/H registers 1 - 97 will be consumed.
In the failing case it will stop at 63 and prevent any further filters from
being added.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c9f53e63c2089d8154900ed06da0aa7be9f74201) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 22 Oct 2015 00:21:20 +0000 (17:21 -0700)]
ixgbevf: Minor cleanups
BugLink: http://bugs.launchpad.net/bugs/1536473
Make some minor cleanups, such as simplifying return paths, deleting
unneeded initializations, return values more directly and so forth.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 50985b5f62cc74e9e222f0ddf890e1ba87be371a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 22 Oct 2015 00:21:15 +0000 (17:21 -0700)]
ixgbevf: Use a private workqueue to avoid certain possible hangs
BugLink: http://bugs.launchpad.net/bugs/1536473
Use a private workqueue to avoid hangs that were otherwise possible
when performing stress tests, such as creating and destroying many
VFS repeatedly.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 40a13e2493c9882cb4d09054d81a5063cd1589a2) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 22 Oct 2015 00:21:10 +0000 (17:21 -0700)]
ixgbe: Use private workqueue to avoid certain possible hangs
BugLink: http://bugs.launchpad.net/bugs/1536473
Use a private workqueue to avoid hangs that were otherwise possible
when performing stress tests, such as creating and destroying many
VFS repeatedly.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 780484d853d096b4253b966e1789c4f338dd7301) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Mon, 19 Oct 2015 16:22:14 +0000 (09:22 -0700)]
ixgbe: Add support for newer thermal alarm
BugLink: http://bugs.launchpad.net/bugs/1536473
The newer copper PHY implementation used with newer X550EM_x
devices uses a different thermal alarm type than the earlier
one. Make changes to support both types.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 83a9fb20ecc4bb8b36a610ab833962fed52db64c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Fri, 16 Oct 2015 20:27:49 +0000 (13:27 -0700)]
ixgbe: Prevent KR PHY reset in ixgbe_init_phy_ops_x550em
BugLink: http://bugs.launchpad.net/bugs/1536473
This patch removes KR PHY reset from ixgbe_init_phy_ops_x550em,
since this function is meant to initialize function pointers for
the detected PHY type. Internal PHY reset was moved to
ixgbe_setup_internal_phy_t_x550em which will now detect which
mode the internal PHY operates in and set it up as required.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f164b84529e3bf9ae43882fd3ac84bef94d104cf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Emil Tantilov [Mon, 12 Oct 2015 17:56:00 +0000 (10:56 -0700)]
ixgbevf: fix spoofed packets with random MAC
BugLink: http://bugs.launchpad.net/bugs/1536473
If ixgbevf is loaded while the corresponding PF interface is down
and the driver assigns a random MAC address, that address can be
overwritten with the value of hw->mac.perm_addr, which would be 0 at
that point.
To avoid this case we init hw->mac.perm_addr to the randomly generated
address and do not set it unless we receive ACK from ixgbe.
Reported-by: John Greene <jogreene@redhat.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 465fc643c2dcbe08e0debac80c225f6750b40d3c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 91a76baadec1f30e8441c3d52c2559468a4da693) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d206563ad8f6fb41943366cf22f1aabc19d2b1a7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 29 Sep 2015 22:19:43 +0000 (15:19 -0700)]
ixgbe/ixgbevf: use napi_schedule_irqoff()
BugLink: http://bugs.launchpad.net/bugs/1536473
The ixgbe_intr and ixgbe/ixgbevf_msix_clean_rings functions run from hard
interrupt context or with interrupts already disabled in netpoll.
They can use napi_schedule_irqoff() instead of napi_schedule()
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ef2662b2a820aaca4c147b91659bf57c06688ede) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The same logic applies here as well as the same results since a netperf
test will starve for memory in the time from one Tx interrupt to the next.
As a result the ixgbevf driver underperformed when compared to vhost_net.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 8a9ca1104da0de6dd8551237e7d0e50eeeea4e80) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Mon, 28 Sep 2015 21:37:47 +0000 (14:37 -0700)]
ixgbe: Add KR mode support for CS4227 chip
BugLink: http://bugs.launchpad.net/bugs/1536473
KR auto-neg mode is what we will be using going forward. The SW
interface for this mode is different that what was used for iXFI.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d91e3a7d624590220e31ccb80a6fb5247cbfa64a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 22 Sep 2015 21:35:41 +0000 (14:35 -0700)]
ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector
BugLink: http://bugs.launchpad.net/bugs/1536473
This patch corrects an issue in which the polling routine would increase
the budget for Rx to at least 1 per queue if multiple queues were present.
This would result in Rx packets being processed when the budget was 0 which
is meant to indicate that no Rx can be handled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5d6002b7b822c7423e75d4651e6790bfb5642b1b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
1) The function name is missing;
2) The format is wrong;
3) The short description is redundant.
Fix all the above for the correct execution of the kernel doc.
Signed-off-by: Jean Sacren <sakiwit@gmail.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a897a2adb602fe3d9223aa59393be07341d3a124) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit cc1f88ba16fa5cc4769cf25dca9fafeb1546be50) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit edab421a57fbdb7f7b83fb494a48c47bc719a7f0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joe Schultz [Tue, 3 Nov 2015 18:37:29 +0000 (12:37 -0600)]
igb: Explicitly label self-test result indices
Previously, the ethtool self-test gstrings/data arrays were accessed via
hardcoded indices, which made the code difficult to follow. This patch
replaces the hardcoded values with enum-based labels.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d602de05934c1d3022b153ff879e81f65df2a7b6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joe Schultz [Tue, 3 Nov 2015 18:37:24 +0000 (12:37 -0600)]
igb: Improve cable length function for I210, etc.
Previously, the PHY-specific code to get the cable length for the
I210 internal and related PHYs was reporting the cable length of a
single pair and reporting it as the min, max, and total cable length.
Update it so that all four pairs are checked so the true min, max,
and average cable lengths are reported.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3627f8f1d137f6487e51ff1199a54a087a2a6446) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Aaron Sierra [Tue, 3 Nov 2015 18:37:18 +0000 (12:37 -0600)]
igb: Don't add PHY address to PCDL address
There is no reason to add the PHY address into the PCDL register address.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 06b0dd64923b5598a52de4c889a116c49493bf97) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Aaron Sierra [Tue, 3 Nov 2015 18:37:09 +0000 (12:37 -0600)]
igb: Remove GS40G specific defines/functions
The I210 internal PHY can be accessed just as well with the access
functions shared by 82580, I350, and I354 devices. A side effect of
relying on the common functions, is that I210 cable length support
is folded back into the common case which effectively reverts the
following commit:
igb: Update get cable length function for i210/i211
Cc: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2a3cdead8b408351fa1e3079b220fa331480ffbc) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jarod Wilson [Mon, 19 Oct 2015 15:52:04 +0000 (11:52 -0400)]
igb: improve handling of disconnected adapters
Clean up array_rd32 so that it uses igb_rd32 the same as rd32, per the
suggestion of Alexander Duyck, and use io_addr in more places, so that
we don't have the need to call E1000_REMOVED (which simply looks for a
null hw_addr) nearly as much.
Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 7b06a6909555ffb0140733cc4420222604140b27) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jan Beulich [Mon, 19 Oct 2015 10:23:29 +0000 (04:23 -0600)]
igb: fix NULL derefs due to skipped SR-IOV enabling
The combined effect of commits 6423fc3416 ("igb: do not re-init SR-IOV
during probe") and ceee3450b3 ("igb: make sure SR-IOV init uses the
right number of queues") causes VFs no longer getting set up, leading
to NULL pointer dereferences due to the adapter's ->vf_data being NULL
while ->vfs_allocated_count is non-zero. The first commit not only
neglected the side effect of igb_sriov_reinit() that the second commit
tried to account for, but also that of setting IGB_FLAG_HAS_MSIX,
without which igb_enable_sriov() is effectively a no-op. Calling
igb_{,re}set_interrupt_capability() as done here seems to address this,
but I'm not sure whether this is better than sinply reverting the other
two commits.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit be06998f96ecb93938ad2cce46c4289bf7cf45bc) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The i210 has two EEPROM access registers that are located in
non-standard offsets: EEARBC and EEMNGCTL. EEARBC was fixed previously
and EEMNGCTL should also be corrected.
Reported-by: Roman Hodek <roman.aud@siemens.com> Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 08c991297582114a6e1220f913eec91789c4eac6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Upon looking at the igb driver, I see that igb_rd32() attempted to read from
hw_addr and failed, so it set hw->hw_addr to NULL and spit out the message
in the log output above, "PCIe link lost, device now detached".
Well, now that hw_addr is NULL, the attempt to call pci_iounmap is obviously
not going to go well. As suggested by Mark Rustad, do something similar to
what ixgbe does, and save a copy of hw_addr as adapter->io_addr, so we can
still call pci_iounmap on it on teardown. Additionally, for consistency,
make the pci_iomap call assignment directly to io_addr, so map and unmap
match.
Signed-off-by: Jarod Wilson <jarod@redhat.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 73bf8048d7c86a20a59d427e55deb1a778e94df7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1536474
Somehow an ID that has never been productized is in the
code. There are no plans to use it, so just get
rid of it.
Change-ID: I59117d48ea9ee0360b0fe33833ac8092f8a24b4c Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 56028154caafab34063324916095618b2cd30c73) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
i40e: Fix Rx hash reported to the stack by our driver
BugLink: http://bugs.launchpad.net/bugs/1536474
If the driver calls skb_set_hash even with a zero hash, that
indicates to the stack that the hash calculation is offloaded
in hardware. So the Stack doesn't do a SW hash which is required
for load balancing if the user decides to turn of rx-hashing
on our device.
This patch fixes the path so that we do not call skb_set_hash
if the feature is disabled.
Change-ID: Ic4debfa4ff91b5a72e447348a75768ed7a2d3e1b 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>
(cherry picked from commit 857942fd1aa15edf7356a4a4bad5369c8e70a633) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
As with that fix, attempt to look up the MAC address in Open Firmware
on systems that support it, and use IDPROM on SPARC if no OF address
is found.
In the case of the i40e there is an assumption that the default mac
address has already been set up as the primary mac filter on probe,
so if this filter is obtained from the Open Firmware or IDPROM, an
explicit write is needed via i40e_aq_mac_address_write() and
i40e_aq_add_macvlan() invocation.
The I40E_FLAG_PF_MAC flag in the platform-private i40e_pf structure
tracks whether a platform-specific mac address was found, in which
case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan()
will be triggered.
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Shannon Nelson <shannon.nelson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b499ffb0a22c6cd3762b44fd6489f7384f40437d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Tue, 22 Dec 2015 23:34:43 +0000 (15:34 -0800)]
i40e: allow zero MAC address for VFs
BugLink: http://bugs.launchpad.net/bugs/1536474
Allow the user to specify a zero MAC address for VFs. This removes the
existing MAC address and allows the VF to use a random address. Libvirt
does this normally when removing a VF from a VM.
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 efd8e39acc51cafe7dbc656ba63eea9034238ee7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Tue, 22 Dec 2015 23:34:42 +0000 (15:34 -0800)]
i40e: change log messages and error returns
BugLink: http://bugs.launchpad.net/bugs/1536474
When VFs are being reset, there is a brief window of time when they
cannot be configured because they don't have a VSI to configure. If
a script is quick, it can fall through that window. To avoid
defenestration, log a useful error message and return -EAGAIN.
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 2d166c304065c57925278a69309f15a6a65eff97) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Singhai, Anjali [Mon, 14 Dec 2015 20:21:21 +0000 (12:21 -0800)]
i40e: Call geneve_get_rx_port to get the existing Geneve ports
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch adds a call to geneve_get_rx_port in i40e so that when it
comes up it can learn about the existing geneve tunnels.
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cd866606c91b1e99517fd866de0049276f011ea7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 05ca4029b25c65c860be5baa9288ec8f7e0a97e6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Singhai, Anjali [Mon, 14 Dec 2015 20:21:18 +0000 (12:21 -0800)]
i40e: geneve tunnel offload support
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch adds driver hooks to implement ndo_ops to add/del
udp port in the HW to identify GENEVE tunnels.
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Signed-off-by: Kiran Patil <kiran.patil@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6a899024058d35dbcac33fbd3c7d70f2a54828e1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Signed-off-by: Kiran Patil <kiran.patil@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a8170d2b9e8d38a1f3fa3b40b6f8cd34a87d5382) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Tom Herbert [Thu, 10 Dec 2015 20:37:45 +0000 (12:37 -0800)]
geneve: UDP checksum configuration via netlink
BugLink: http://bugs.launchpad.net/bugs/1536474
Add support to enable and disable UDP checksums via netlink. This is
similar to how VXLAN and GUE allow this. This includes support for
enabling the UDP zero checksum (for both TX and RX).
Signed-off-by: Tom Herbert <tom@herbertland.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(back ported from commit abe492b4f50c3ae2ebcfaa2f5c16176aebaa1c68) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Thu, 19 Nov 2015 19:34:24 +0000 (11:34 -0800)]
i40evf: change version string generation
BugLink: http://bugs.launchpad.net/bugs/1536474
Generate version strings like the PF driver does. This gives us more
flexibility to add suffixes to the version string at build time.
Change-ID: I0a5ca0783dd8fb849516bfc1e37ea070127847bd 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 69ebe955be358fe8f8c73b3aa7395760f337845f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Shannon Nelson [Thu, 19 Nov 2015 19:34:23 +0000 (11:34 -0800)]
i40e: clean whole mac filter list
BugLink: http://bugs.launchpad.net/bugs/1536474
Clean the whole mac filter list when resetting after an intermediate
add or delete push to the firmware. The code had evolved from using
a list from the stack to a heap allocation, but the memset() didn't
follow the change correctly. This now cleans the whole list rather
that just part of the first element.
Change-ID: I4cd03d5a103b7407dd8556a3a231e800f2d6f2d5 Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f11999987bc0b5559ab56dedc6f4ca32fab5438a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Thu, 19 Nov 2015 19:34:21 +0000 (11:34 -0800)]
i40e: hush little warnings
BugLink: http://bugs.launchpad.net/bugs/1536474
These messages seem big and scary, but they're really not. The driver
can fully recover from any of these. The overflow error in particular
can happen when enabling a bunch of VFs and the VF driver is not
blacklisted.
Since these messages are really for debugging purposes, reclassify
them as such.
Change-ID: I628d0f5e135e7063450ba05393a50b7af23aa6d7 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 75eb73c127beaccf1b2c825f5d583ebca17ab2ba) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Michal Kosiarz [Thu, 19 Nov 2015 19:34:20 +0000 (11:34 -0800)]
i40e: Opcode and structures required by OEM Post Update AQ command and add new NVM arq message
BugLink: http://bugs.launchpad.net/bugs/1536474
This is a part of implementation which contains data structures and
opcode for new AQ command. There's a new ARQ message that gets sent
near the end of the NVM update process that the driver should recognize
and ignore, rather than printing an Unknown Event error.
Change-ID: I04830a5bcae14823e16b9424cc4165e169336c1f Signed-off-by: Michal Kosiarz <michal.kosiarz@intel.com> Acked-by: Shannon Nelson <shannon.nelson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 00ada50d8989ed14b160d831d25fe09bf9ea9115) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Thu, 19 Nov 2015 19:34:18 +0000 (11:34 -0800)]
i40evf: check rings before freeing resources
BugLink: http://bugs.launchpad.net/bugs/1536474
If the driver gets unloaded during reset recovery, it's possible
that it will attempt to free resources when they're already free.
Add a check to make sure that the Tx and Rx rings actually exist
before dereferencing them to free resources.
Change-ID: I4d2b7e9ede49f634d421a4c5deaa5446bc755eee 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 fdb47ae87af537b24977a03bc69cfe1c5c55ca62) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Thu, 19 Nov 2015 19:34:17 +0000 (11:34 -0800)]
i40e: don't add zero MAC filter
BugLink: http://bugs.launchpad.net/bugs/1536474
When VFs are created, the MAC address defaults to all zeros, indicating
to the VF driver that it should use a random MAC address. However, the
PF driver was incorrectly adding this zero MAC to the filter table,
along with the VF's randomly generated MAC address.
Check for a good address before adding the default filter. While we're
at it, make the error message a bit more useful.
Change-ID: Ia100947d68140e0f73a19ba755cbffc3e79a8fcf 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 b7b713a8eaf325607d37229f024ad0b9f3e7f320) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Thu, 19 Nov 2015 19:34:16 +0000 (11:34 -0800)]
i40e: properly delete VF MAC filters
BugLink: http://bugs.launchpad.net/bugs/1536474
The virtual channel interface was using incorrect semantics to remove
MAC addresses, which would leave incorrect filters active when using
VLANs. To correct this, add a new function that unconditionally removes
MAC addresses from all VLANs, and call this function when the VF
requests a MAC filter removal.
Change-ID: I69826908ae4f6c847f5bf9b32f11faa760189c74 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 b36e9ab59b7e3a5b14bf88dc0536e6579db7b54d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jesse Brandeburg [Thu, 19 Nov 2015 19:34:14 +0000 (11:34 -0800)]
i40e: chomp the BIT(_ULL)
BugLink: http://bugs.launchpad.net/bugs/1536474
BIT_ULL was used on a u32 or less where it can simply be BIT. This
fixes some trivial static analyzer warnings. Chomp, chomp.
Tested with objdump of binary before and after, no changes to code.
Change-ID: I6245e9abd447192dbde1669c747aeb2878126c7d Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 75f5cea9ddef6a8f8cedb86c0ac8c696b258824d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6633d3815c099a0aaf28e4853f7a8994331b8c05) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joe Perches [Thu, 3 Dec 2015 12:20:57 +0000 (04:20 -0800)]
i40e: Fix i40e_print_features() VEB mode output
BugLink: http://bugs.launchpad.net/bugs/1536474
Commit 7fd89545f337 ("i40e: remove BUG_ON from feature string building")
added defective output when I40E_FLAG_VEB_MODE_ENABLED was set in
function i40e_print_features.
Fix it.
Miscellanea:
- Remove unnecessary string variable
- Add space before not after fixed strings
- Use kmalloc not kzalloc
- Don't initialize i to 0, use result of first snprintf
Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3b195843f59b8aefdc15c689615745bf6758756c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jesse Brandeburg [Thu, 19 Nov 2015 01:35:42 +0000 (17:35 -0800)]
i40e: trivial fixes
BugLink: http://bugs.launchpad.net/bugs/1536474
1) remove duplicate include of tcp.h
2) put an ampersand at the end of a line instead of the beginning
3) remove a useless dev_info
4) match declaration of function to the implementation
5) repair incorrect comment
6) correct whitespace
7) remove unused define
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 4eeb1fff27f4578386955b0e88f4cffc3814df24) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Fri, 6 Nov 2015 23:26:11 +0000 (15:26 -0800)]
i40e/i40evf: use logical operator
BugLink: http://bugs.launchpad.net/bugs/1536474
We shouldn't be using a bitwise operator here; it's not a bitwise
operation. Use a logical operator instead. Why doesn't c have a
logical-or-and-assign operator?
Change-ID: Id84f3ca884910bed7073c84b1e16a102e958d0de 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 44cdb791ae7bc40e0331b78a73992be44079a3ec) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Change-ID: I64735e9aa8618b9a5059a87ace1c999d6d3bfcfb 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 b82bc49ede1f012d37ba8777e8232cd7c01365cd) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Neerav Parikh [Fri, 6 Nov 2015 23:26:09 +0000 (15:26 -0800)]
i40e: Remove separate functions gathering XOFF Rx stats
BugLink: http://bugs.launchpad.net/bugs/1536474
The separate functions to gather Flow control Rx XOFF stats was to
determine if the Tx for a queue was paused due to Link Flow Control(LFC)
or Priority Flow Control(PFC).
But, with recent change in the i40e driver the logic for checking th Tx
hang has been removed and these functions don't do anything meaningful.
Hence, there is no need to keep these separate functions to gather Rx
XOFF stats for LFC or PFC.
This patch removes these functions and moves the stat collection for
XOFF Rx to the i40e_update_pf_stats() that collects all the PF stats.
Change-ID: Iec1452dac3a6766f0d968e754cb407530d7c60cd Signed-off-by: Neerav Parikh <neerav.parikh@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 95db239f4fc664d9ce4ba9a6a3e87d2a3d856a23) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1536474
Instead of having our own custom symbol, we can just rely
on whether or not the kernel has the feature enabled.
In this case use IS_ENABLED(CONFIG_VXLAN) in order to handle
built-in or module in the current BKM way.
Change-ID: I5890fbb518ff8ed6bb07c3362fb0a8a829f9b241 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 8fe269991aece394a7ed274f525d96c73f94109a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1536474
Ethtool priv flags implementation to enable or disable packet split, which
is a hardware feature that inspects headers and will put headers in a
separate DMA buffer from the payload data. The driver was automatically
choosing to enable packet split in some cases and this gives the user the
ability to turn it off/on explicitly.
to query state:
ethtool --show-priv-flags ethx
to enable:
ethtool --set-priv-flags ethx packet-split on
to disable:
ethtool --set-priv-flags ethx packet-split off
Why would anyone want this?
Because some environments benefit from header/data split in the receive
buffer, and the driver defaults to one or the other depending on
environment/kernel parameters.
Why didn't you implement a generic ethtool control for this feature?
Because Intel hardware is the only hardware that supports header/data
split.
Change-ID: I803121e1eecc9ccb2884031fd85dd1110b3af66d Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 827de39212298048e75309377c8262c4d7f2cb41) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Change-ID: I77bbf3b6464edaef747c7104b43534032a4dba63 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 d82acb353246d3989377761ca26f5489264a4793) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Mon, 9 Nov 2015 23:35:50 +0000 (15:35 -0800)]
i40e: propagate properly
BugLink: http://bugs.launchpad.net/bugs/1536474
i40e_sync_vsi_filters() is the surly teenager of this driver. It says
it's going to report errors, but it doesn't actually do that most of the
time. And when it does, it leaves a mess.
Change this function to have a common exit point so it will properly
release the busy lock on the VSI. Propagate errors to the callers.
Finally, adjust a few callers to check for and deal with errors from
this function.
Change-ID: Ic6af4956491e72402ebb3c538a3c31a0ad7f8667 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 ea02e90b4b49782462d06a425e05c776909fbae4) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Fri, 6 Nov 2015 23:26:04 +0000 (15:26 -0800)]
i40evf: don't use atomic allocation
BugLink: http://bugs.launchpad.net/bugs/1536474
These allocations don't need to be at atomic level. GFP_KERNEL is fine
and they'll reduce stress on the allocator when the system is starved
for memory.
Change-ID: I3561d0399a681de0ad25291b6c848b224c1fde12 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 a85088d813a3ac44afa237113539585257127cfa) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch fixes the memory leak which would be seen otherwise when user
programs flow-director filter using ethtool (sideband filter programming).
When ethtool is used to program flow directory filter, 'raw_buf' gets
allocated and it is supposed to be freed as part of queue cleanup. But
check of 'tx_buffer->skb' was preventing it from being freed.
Change-ID: Ief4f0a1a32a653180498bf6e987c1b4342ab8923 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 a42e7a369ea2b73a554a85dea7d6243af51cd4f0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Kiran Patil [Fri, 6 Nov 2015 23:26:02 +0000 (15:26 -0800)]
i40e: Detection and recovery of TX queue hung logic moved to service_task from tx_timeout
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch contains following changes:
- detection and recovery logic (issue SW interrupt) has been moved to
service_task from timeout function.
- added some more debug info from tx_timeout.
Logic to detect and recover TX queue hung is now two step process:
- service_task detects TX queue hung and sets a bit(hung_detected) if
it was not set.
- if bit was set (means this is back-back hung condition detected),
issue SW interrupt and clear the bit.
- napi_poll clears the bit unconditionally since it cleans TX/RX queues.
Change-ID: Ieed03a48927c845a988b3ff375090bf37caeb903 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 9c6c12595b73e580f103b0812837f015034d460e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Fri, 6 Nov 2015 23:26:01 +0000 (15:26 -0800)]
i40evf: remove duplicate string
BugLink: http://bugs.launchpad.net/bugs/1536474
We already print the driver info string in probe, so don't print
it again in init. No need to repeat. No need to repeat.
Change-ID: Ief597997f580a8c54d5950e3a84c29f2075be66b 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 05281eb8e1754688ecf07a63844c56c9f76b38ad) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Change-ID: I67982799de3f248fb4158ccdc9b1a74385f42ddd 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 e6c4cf6fb9323c0f65b8fef1c0c8c9e15b51007e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Fri, 6 Nov 2015 23:25:59 +0000 (15:25 -0800)]
i40evf: increase max number of queues
BugLink: http://bugs.launchpad.net/bugs/1536474
Future devices will allow for more queue pairs, so allocate a netdev
that can handle them. While we're at it, get rid of the separate
MAX_TX/MAX_RX defines. Since we always get matched queue pairs, having
these makes no sense.
Change-ID: I0e3556cd9a962506e509eb7c0afa36b329e8cb51 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 1255b7a12ec4b6174a1c84f4aae4370b8ba1b1cf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1536474
With the final edition of the patches to remove sleeps from
the driver's entry points, the grab_rtnl argument is no
longer needed, so partially revert the commit that added it.
Change-ID: Ib9778476242586cc9e58b670f5f48d415cb59003 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 17652c6336fdca0f48906f0a1d9b5ac77b29e5a7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1536474
The driver was being called by VLAN, bonding, teaming operations
that expected to be able to hold locks like rcu_read_lock().
This causes the driver to be held to the requirement to not sleep,
and was found by the kernel debug options for checking sleep
inside critical section, and the locking validator.
Change-ID: Ibc68c835f5ffa8ffe0638ffe910a66fc5649a7f7 Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 0e4425ed641f3eef67c892bc541949cd745a9ba9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Mon, 26 Oct 2015 23:44:40 +0000 (19:44 -0400)]
i40evf: allocate ring structs dynamically
BugLink: http://bugs.launchpad.net/bugs/1536474
Instead of awkwardly keeping a fixed array of pointers in the adapter
struct and then allocating ring structs individually, just keep a single
pointer and allocate a single blob for the arrays. This simplifies code,
shrinks the adapter structure, and future-proofs the driver by not
limiting the number of rings we can handle.
Change-ID: I31334ff911a6474954232cfe4bc98ccca3c769ff 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 0dd438d8ad5db85c1a805ce2244252e37d5586a0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Mon, 26 Oct 2015 23:44:39 +0000 (19:44 -0400)]
i40evf: allocate queue vectors dynamically
BugLink: http://bugs.launchpad.net/bugs/1536474
Change the queue_vector array from a statically-sized member of the
adapter structure to a dynamically-allocated and -sized array.
This reduces the size of the adapter structure, and allows us to support
any number of queue vectors in the future without changing the code.
Change-ID: I08dc622cb2f2ad01e832e51c1ad9b86524730693 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 7d96ba1a8b7c36d1f4a04dc40e031b6f8c677496) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Mon, 26 Oct 2015 23:44:38 +0000 (19:44 -0400)]
i40evf: quoth the VF driver, Nevermore
BugLink: http://bugs.launchpad.net/bugs/1536474
If, upon a midnight dreary, the PF returns ERR_PARAM when the VF is
requesting resources, that's fatal. Either the firmware or NVM is badly,
badly misconfigured, or this VF has been disabled due to a previous VF
driver sending a bunch of bogus messages.
Either way, there is no recovery from this. Don't ponder weak and weary,
just quit.
Change-ID: I09d9f16cc4ee7fec3b57646a289d33838c1c5bf5 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 e743072fd16e6e772d5b5e4aef38873946f9a3e0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Mon, 26 Oct 2015 23:44:37 +0000 (19:44 -0400)]
i40e: make error message more useful
BugLink: http://bugs.launchpad.net/bugs/1536474
If we get an invalid message from a VF, we should tell the user which VF
is being naughty, rather than making them guess.
Change-ID: I9252cef7baea3d8584043ed6ff12619a94e2f99c 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 e7ffb72d65c784ba445ac849bd46d2533365fae7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Helin Zhang [Mon, 26 Oct 2015 23:44:36 +0000 (19:44 -0400)]
i40e: fix confusing message
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch fixes the confusing kernel message of enabled RSS size,
by reporting it together with the hardware maximum RSS size.
Change-ID: I64864dbfbc13beccc180a7871680def1f3d5a339 Signed-off-by: Helin Zhang <helin.zhang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e36b0b111bcc651ce030e88e042f83b015dd04b8) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Carolyn Wyborny [Mon, 26 Oct 2015 23:44:35 +0000 (19:44 -0400)]
i40e: Update error messaging
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch fixes an issue where adminq init failures always provided
a message that NVM was newer than expected. This is not always the
case for init_adminq failures. Without this patch, if adminq init
fails for any reason, newer NVM message would be given. This
problem is fixed by adding a check for that specific error
condition and a different hopefully helpful message otherwise.
Change-ID: Iaeaebee4e398989eae40bb70f943ab66a3a521a5 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 2b2426a760764017cb53ffae128c87b7808dcf11) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Helin Zhang [Mon, 26 Oct 2015 23:44:33 +0000 (19:44 -0400)]
i40evf: create a generic get RSS function
BugLink: http://bugs.launchpad.net/bugs/1536474
There are two ways to get RSS, this patch implements two functions
with the same input parameters, and creates a more generic function
for getting RSS configuration.
Change-ID: I12d3b712c21455d47dd0a5aae58fc9b7c680db59 Signed-off-by: Helin Zhang <helin.zhang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 90b02b4392eb9778265ec6b4fef034010a937910) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Helin Zhang [Tue, 27 Oct 2015 20:15:06 +0000 (16:15 -0400)]
i40evf: create a generic config RSS function
BugLink: http://bugs.launchpad.net/bugs/1536474
There are two ways to configure RSS, this patch adjusts those two
functions with the same input parameters, and creates a more
generic function for configuring RSS.
Change-ID: Iace73bdeba4831909979bef221011060ab327f71 Signed-off-by: Helin Zhang <helin.zhang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2c86ac3c70794f0ecc3684b0ae0fd75b0cf0c1f6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jesse Brandeburg [Mon, 26 Oct 2015 23:44:30 +0000 (19:44 -0400)]
i40e/i40evf: prefetch skb data on transmit
BugLink: http://bugs.launchpad.net/bugs/1536474
Issue a prefetch for data early in the transmit path.
This should not be generally needed for Tx traffic, but
it helps immensely for pktgen workloads and should help
for forwarding workloads as well.
Change-ID: Iefee870c20599e0c4240e1d8637e4f16b625f83a Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b74118f08356fd8ab6cb5d1a15705a2760c9afdd) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Without this patch we were forcing WB/arming interrupt too often taking
away the benefits of NAPI and causing a performance impact.
With this patch we disable force WB in the clean routine for X710
and XL710 adapters. X722 adapters do not enable interrupt to force
a WB and benefit from WB_ON_ITR and hence force WB is left enabled
for those adapters.
For XL710 and X710 adapters if we have less than 4 packets pending
a software Interrupt triggered from service task will force a WB.
This patch also changes the conditions for setting RS bit as described
in code comments. This optimizes when the HW does a tail bump amd when
it does a WB. It also optimizes when we do a wmb.
Change-ID: Id831e1ae7d3e2ec3f52cd0917b41ce1d22d75d9d 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>
(cherry picked from commit 6a7fded776a778f728b13d83a2c9fc893580c080) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Helin Zhang [Mon, 26 Oct 2015 23:44:28 +0000 (19:44 -0400)]
i40e: rename rss_size to alloc_rss_size in i40e_pf
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch renames rss_size to alloc_rss_size in i40e_pf, which is
clearer and avoids confusion. It also adds comments to the other
related structure members to help clarify usage.
Change-ID: Ia90090609d006ab589cb639975bb8a0af795d16f Signed-off-by: Helin Zhang <helin.zhang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit acd65448f2e6b3407b8bb28b57d711ca417ea679) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Helin Zhang [Wed, 21 Oct 2015 23:56:23 +0000 (19:56 -0400)]
i40e: create a generic configure rss function
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch renames the old pf-specific function in order to clarify
its scope. This patch also creates a more generic configure RSS
function with the old name.
This patch also creates a new more generic function to get RSS
configuration, using the appropriate method.
Change-ID: Ieddca2707b708ef19f1ebccdfd03a0a0cd63d3af Signed-off-by: Helin Zhang <helin.zhang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 043dd650efde3dfc65a6461e1cdc51cc87cb76f7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Helin Zhang [Wed, 21 Oct 2015 23:47:13 +0000 (19:47 -0400)]
i40e: return the number of enabled queues for ETHTOOL_GRXRINGS
BugLink: http://bugs.launchpad.net/bugs/1536474
This patch fixes a problem where using ethtool rxnfc command could
let RX flow hash be set on disabled queues. This patch fixes the
problem by returning the number of enabled queues before setting
rxnfc.
Change-ID: Idbac86b0b47ddacc8deee7cd257e41de01cbe5c0 Signed-off-by: Helin Zhang <helin.zhang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3e3aa21fe9265bdc45ff795dbcc90bcdd2f1017c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Wed, 21 Oct 2015 23:47:12 +0000 (19:47 -0400)]
i40evf: handle many MAC filters correctly
BugLink: http://bugs.launchpad.net/bugs/1536474
When a lot (many hundreds) of MAC or VLAN filters are added at one time,
we can overflow the Admin Queue buffer size with all the requests.
Unfortunately, the driver would then calculate the message size
incorrectly, causing it to be rejected by the PF. Furthermore, there was
no mechanism to trigger another request to allow for configuring the
rest of the filters that didn't fit into the first request.
To fix this, recalculate the correct buffer size when we detect the
overflow condition instead of just assuming the max buffer size. Also,
don't clear the request bit in adapter->aq_required when we have an
overflow, so that the rest of the filters can be processed later.
Change-ID: Idd7cbbc5af31315e0dcb1b10e6a02ad9817ce65c 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 1418c3458118c6969d08e23aa377da7e2a7be36c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mitch Williams [Wed, 21 Oct 2015 23:47:11 +0000 (19:47 -0400)]
i40e/i40evf: clean up error messages
BugLink: http://bugs.launchpad.net/bugs/1536474
Clean up and enhance error messages related to VF MAC/VLAN filters.
Indicate which VF is having issues, and if possible indicate the MAC
address or VLAN involved.
Also, when an error is returned from the PF driver, print useful
information about what went wrong, for the most likely cases.
Change-ID: Ib3d15eef9e3369a78fd142948671e5fa26d921b8 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 8d8f2295d0752230e0a697af33e5af96561b64a0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
i40e: Move the saving of old link info from handle_link_event to link_event
BugLink: http://bugs.launchpad.net/bugs/1536474
The watchdog only calls link_event not handle_link_event which means
that we need to save the old information in link_event.
Previously when polling we were comparing current data to the old data
saved the last time we actually received a link event. This means that
the polling would only fix link status changes in one direction
depending on what the last old data saved off was.
Change-ID: Ie590f30fdbcb133d0ddad4e07e3eb1aad58255b3 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 1f9610e4777c391e1e749ffc646b29dbff920834) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
i40e/i40evf: Add a stat to track how many times we have to do a force WB
BugLink: http://bugs.launchpad.net/bugs/1536474
When in NAPI with interrupts disabled, the HW needs to be forced to do a
write back on TX if the number of descriptors pending are less than a
cache line.
This stat helps keep track of how many times we get into this situation.
Change-ID: I76c1bcc7ebccd6bffcc5aa33bfe05f2fa1c9a984 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>
(cherry picked from commit 164c9f54631beca4d174f306acdcaec2bdeef52e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>