Don Skidmore [Fri, 16 Dec 2016 02:18:31 +0000 (21:18 -0500)]
ixgbevf: Add support for VF promiscuous mode
This patch extends the mailbox message to allow for VF promiscuous
mode support.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 41e544cdad0bd669600825d8de73c8f420640bf9)
Chunk in ixgbevf_main.c deleted due to dependencies Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Mark Rustad [Wed, 14 Dec 2016 19:02:00 +0000 (11:02 -0800)]
ixgbe: Fix issues with EEPROM access
There are two problems with EEPROM access. One is that it needs to
hold the semaphore until the entire response is read or else the
response can be corrupted by other firmware accesses. The second
problem is that acquiring and releasing the semaphore is slow, so
it should be taken and released once when multiple EEPROM accesses
will be done.
Both of these issues can be solved by adding a new function,
ixgbe_hic_unlocked, to issue firmware commands that will assume
that the caller has acquired the needed semaphore.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 3efa9ed260ce838976eb9177bae7249caf7a2aa1) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Don Skidmore [Wed, 14 Dec 2016 01:34:51 +0000 (20:34 -0500)]
ixgbe: Configure advertised speeds correctly for KR/KX backplane
This patch ensures that the advertised link speeds are configured
for X553 KR/KX backplane. Without this patch the link remains at
1G when resuming from low power after being downshifted by LPLU.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 54f6d4c42451dbd2cc7e0f0bd8fc3eddcab511fe) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Yusuke Suzuki [Mon, 21 Nov 2016 06:48:45 +0000 (06:48 +0000)]
ixgbe: Fix incorrect bitwise operations of PTP Rx timestamp flags
Rx timestamp does not work on 82599 and X540 because bitwise operation
of RX_HWTSTAMP flags is incorrect and ixgbe_ptp_rx_hwtstamp() is never
called. This patch fixes it to enable Rx timestamp on 82599 and X540.
Without this fix:
ptp4l[278.730]: selected /dev/ptp8 as PTP clock
ptp4l[278.733]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[278.733]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[278.834]: port 1: received SYNC without timestamp
ptp4l[278.835]: port 1: new foreign master 1c3947.fffe.60f9cc-1
ptp4l[279.834]: port 1: received SYNC without timestamp
ptp4l[280.834]: port 1: received SYNC without timestamp
ptp4l[281.834]: port 1: received SYNC without timestamp
ptp4l[282.834]: port 1: received SYNC without timestamp
ptp4l[282.835]: selected best master clock 1c3947.fffe.60f9cc
ptp4l[282.835]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[283.834]: port 1: received SYNC without timestamp
With this fix:
ptp4l[239.154]: selected /dev/ptp8 as PTP clock
ptp4l[239.157]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[239.157]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[240.989]: port 1: new foreign master 1c3947.fffe.60f9cc-1
ptp4l[244.989]: selected best master clock 1c3947.fffe.60f9cc
ptp4l[244.989]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[246.977]: master offset -899583339542096 s0 freq +0 path delay 16222
ptp4l[247.977]: master offset -899583339617265 s1 freq -75169 path delay 16177
ptp4l[248.977]: master offset -130 s2 freq -75299 path delay 16177
ptp4l[248.977]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[249.977]: master offset -9 s2 freq -75217 path delay 16177
ptp4l[250.977]: master offset 88 s2 freq -75123 path delay 16132
Fixes: a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices") Signed-off-by: Yusuke Suzuki <yus-suzuki@uf.jp.nec.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit aeb4c73100be8aade8a1189b50bd226b709ca8bb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Emil Tantilov [Wed, 16 Nov 2016 19:25:34 +0000 (11:25 -0800)]
ixgbevf: fix AER error handling
Make sure that we free the IRQs in ixgbevf_io_error_detected() when
responding to an PCIe AER error and also restore them when the
interface recovers from it.
Previously it was possible to trigger BUG_ON() check in free_msix_irqs()
in the case where we call ixgbevf_remove() after a failed recovery from
AER error because the interrupts were not freed.
Also moved the down and free functions into ixgbevf_close_suspend()
same as with ixgbe.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit b19cf6eea9e2a497e6475fd02c0703f0b3a6d083) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Emil Tantilov [Wed, 16 Nov 2016 17:48:02 +0000 (09:48 -0800)]
ixgbe: fix AER error handling
Make sure that we free the IRQs in ixgbe_io_error_detected() when
responding to an PCIe AER error and also restore them when the
interface recovers from it.
Previously it was possible to trigger BUG_ON() check in free_msix_irqs()
in the case where we call ixgbe_remove() after a failed recovery from
AER error because the interrupts were not freed.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 126db13fa0e6d05c9f94e0125f61e773bd5ab079) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Ken Cox [Tue, 15 Nov 2016 19:00:37 +0000 (13:00 -0600)]
ixgbe: test for trust in macvlan adjustments for VF
There are two methods for setting mac addresses in a Macvlan, that
differentiate themselves in the function macvlan_set_mac_Address.
If the macvlan mode is passthru, then we use the dev_set_mac_address
method, otherwise we use the dev_uc api via macvlan_sync_addresses.
The latter method (which would stem from using any non-passthru mode,
like bridge, or vepa), calls down into the driver in a path that terminates
in ixgbevf_set_uc_addr_vf, which sends a IXGBE_VF_SET_MACVLAN message,
which causes the pf to spawn the noted error message. This occurs because
it appears that the guest is trying to delete the mac address of the macvlan
before adding another.
The other path in macvlan_set_mac_address uses dev_set_mac_address, which
calls into ixgbevf_set_mac which uses the IXGBE_VF_SET_MAC_ADDR to the
pf to set the macvlan mac address.
The discrepancy here is in the handlers. The handler function for
IXGBE_VF_SET_MAC_ADDR (ixgbe_set_vf_mac_addr) has a check for
the vfinfo[].trusted bit to allow the operation if the vf is trusted.
In comparison, the IXGBE_VF_SET_MACVLAN message handler
(ixgbe_set_vf_macvlan_msg) has no such check of the trusted bit.
Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit a9d2d53a788a9c5bc8a7d1b4ea7857b68e221357) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Emil Tantilov [Fri, 11 Nov 2016 18:12:51 +0000 (10:12 -0800)]
ixgbevf: handle race between close and suspend on shutdown
When an interface is part of a namespace it is possible that
ixgbevf_close() may be called while ixgbevf_suspend() is running
which ends up in a double free WARN and/or a BUG in free_msi_irqs()
To handle this situation we extend the rtnl_lock() to protect the
call to netif_device_detach() and check for !netif_device_present()
to avoid entering close while in suspend.
Also added rtnl locks to ixgbevf_queue_reset_subtask().
CC: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 2dad7b2775ea030c898fe4946971edd25af237d1) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Emil Tantilov [Fri, 11 Nov 2016 18:07:47 +0000 (10:07 -0800)]
ixgbe: handle close/suspend race with netif_device_detach/present
When an interface is part of a namespace it is possible that
ixgbe_close() may be called while __ixgbe_shutdown() is running
which ends up in a double free WARN and/or a BUG in free_msi_irqs().
To handle this situation we extend the rtnl_lock() to protect the
call to netif_device_detach() and ixgbe_clear_interrupt_scheme()
in __ixgbe_shutdown() and check for netif_device_present()
to avoid clearing the interrupts second time in ixgbe_close();
Also extend the rtnl lock in ixgbe_resume() to netif_device_attach().
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit f7f37e7ff2b9b7eff7fbd035569cab35896869a3) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tony Nguyen [Fri, 11 Nov 2016 00:00:33 +0000 (16:00 -0800)]
ixgbe: Fix reporting of 100Mb capability
BaseT adapters that are capable of supporting 100Mb are not reporting this
capability. This patch corrects the reporting so that 100Mb is shown as
supported on those adapters.
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit f215266470dfe86196a31fe0725a86cea77f9a18) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tony Nguyen [Thu, 10 Nov 2016 17:57:29 +0000 (09:57 -0800)]
ixgbe: Reduce I2C retry count on X550 devices
A retry count of 10 is likely to run into problems on X550 devices that
have to detect and reset unresponsive CS4227 devices. So, reduce the I2C
retry count to 3 for X550 and above. This should avoid any possible
regressions in existing devices.
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 3f0d646b720d541309b11e190db58086f446f41e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tony Nguyen [Wed, 9 Nov 2016 18:48:48 +0000 (10:48 -0800)]
ixgbe: Add bounds check for x540 LED functions
This is an extension of commit 003287e0f087 ("ixgbevf: Correct parameter
sent to LED function"); add bounds checking to x540 functions to ensure the
index is valid.
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 910c9c0f59567ec204924d88ca04337bb04f17d9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tony Nguyen [Mon, 31 Oct 2016 19:11:58 +0000 (12:11 -0700)]
ixgbe: Fix check for ixgbe_phy_x550em_ext_t reset
The generic PHY reset check we had previously is not sufficient for the
ixgbe_phy_x550em_ext_t PHY type. Check 1.CC02.0 instead - same as
ixgbe_init_ext_t_x550().
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit 5c092749e304d8b49567be633d5be31393538e3b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tony Nguyen [Wed, 26 Oct 2016 23:25:18 +0000 (16:25 -0700)]
ixgbe: Report driver version to firmware for x550 devices
Some x550 devices require the driver version reported to its firmware; this
patch sends the driver version string to the firmware through the host
interface command for x550 devices.
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26242766
(cherry picked from commit cb8e051446ae554aae38163d3421edc793221784) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Vijay Kumar [Wed, 1 Feb 2017 19:34:40 +0000 (11:34 -0800)]
Documentation/sparc: Steps for sending break on sunhv console
Documented the steps for sending break on sunhv console.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4cfe140618b99e653134598de9f18b48743549ec)
Vijay Kumar [Wed, 1 Feb 2017 19:34:39 +0000 (11:34 -0800)]
sparc64: Send break twice from console to return to boot prom
Now we can also jump to boot prom from sunhv console by sending
break twice on console for both running and panicked kernel
cases.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7db60d05e5ccc0a473fa2275f90f2fca0002ab21)
Vijay Kumar [Wed, 1 Feb 2017 19:34:38 +0000 (11:34 -0800)]
sparc64: Migrate hvcons irq to panicked cpu
On panic, all other CPUs are stopped except the one which had
hit panic. To keep console alive, we need to migrate hvcons irq
to panicked CPU.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 7dd4fcf5b70694dc961eb6b954673e4fc9730dbd)
Vijay Kumar [Wed, 1 Feb 2017 19:34:37 +0000 (11:34 -0800)]
sparc64: Set cpu state to offline when stopped
CPU needs to be marked offline before stopping it. When not marked
offline, the xcall receives HV_EWOULDBLOCK and so assumes that not all
CPUs received the message, and retries. After 10000 retries, it finally
fails with fatal mondo timeout.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cffb3e76818fee4763a2ce5f2b1eca2d7885e2cf)
Since the tcmu feature support for the iscsi target is added by below
bug fixes build the tcmu kernel module by modifying default kernel
configuration files.
The fixes which add tcmu feature to the iscsi target:
Orabug: 25983319/25983379/25791789 Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Shan Hai <shan.hai@oracle.com>
Over-eager editing for conflict resolution in merge commit c311ca8a3d9349dfc606cada0d8ca14e58728c9c ("Merge tag 'v4.1.12-70#22913653a12'
into pmem-4.1-merge") resulted in the accidental deletion of two calls to
mutex_lock(). Since the matching calls to mutex_unlock() were correctly left
in the source, this produced a lock imbalance, detectable via lockdep.
This commit restores the missing mutex_lock() calls.
md/raid5: don't index beyond end of array in need_this_block().
When need_this_block probably shouldn't be called when there
are more than 2 failed devices, we really don't want it to try
indexing beyond the end of the failed_num[] of fdev[] arrays.
So limit the loops to at most 2 iterations.
Reported-by: Shaohua Li <shli@fb.com> Signed-off-by: NeilBrown <neilb@suse.de>
(cherry picked from commit 36707bb2e7c6730d79d6cdc6d1475d3d7e94c518)
Orabug: 26047272 Signed-off-by: Fred Herard <fred.herard@oracle.com> Reviewed-by: John Sobecki <john.sobecki@oracle.com>
Signed-off-by: Nicolas Droux <nicolas.droux@oracle.com> Acked-by: Saar Maoz <Saar.Maoz@oracle.com> Acked-by: Rajan Shanmugavelu <rajan.shanmugavelu@oracle.com> Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Jacob Keller [Fri, 10 Mar 2017 20:22:05 +0000 (12:22 -0800)]
i40e: remove FDIR_REQUIRES_REINIT driver flag
This flag hasn't been used since commit 1e1be8f622ee ("i40e: ATR policy
change to flush the table to clean stale ATR rules").
Lets simplify things and just remove it.
Change-ID: I76279d84db8a2fd96f445b96aa413059f9256879 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3a104f8df2ca87d6d116eae5f2442b57dc3baec4) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 10 Mar 2017 20:22:04 +0000 (12:22 -0800)]
i40e: remove a useless goto statement
The goto found here for when in MFP mode is pointless. It jumps to the
end of a series of if blocks. However, right after this statement is
a closing '}' for this if block, which will result in the program flow
going to the exact same location as the goto statement indicates. Thus,
regardless of whether we are in MFP mode, the program flow will resume
from the same location.
This arose due to various refactoring which did not notice that this
goto became essentially a no-op.
To properly understand this diff you will need to view a larger context
than is given by default.
Change-ID: I088f73c3831aa5c4e2281380c7a3ce605594300c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d9eaf12e853f8cd63633434fe9f753098012167f) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Christopher N Bednarz [Fri, 10 Mar 2017 20:22:03 +0000 (12:22 -0800)]
i40e: Check for new arq elements before leaving the adminq subtask loop
Fix a case where we miss an arq element if a new one is added before we
enable interrupts and exit the arq subtask loop. This occurs frequently
with RDMA running on Windows VF and causes long delays that prevent SMB
from establishing connections.
Change-ID: I3e1c8b2b960c12857d9b8275bea2c1563674392e Signed-off-by: Christopher N Bednarz <christopher.n.bednarz@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 1fca3265be916f45bcdf4f0207bcc99d0f6c1b7d) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Paul M Stillwell Jr [Fri, 10 Mar 2017 20:22:02 +0000 (12:22 -0800)]
i40e: use register for XL722 control register read/write
The XL722 doesn't support the AQ command to read/write the control
register so enable it to bypass the check and use the direct read/write
method.
Change-ID: Iefecc737b57207485c90845af5989d5af518bf16 Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 6030308ef8e5917da2f606abdbb893435d119b28) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alexander Duyck [Fri, 10 Mar 2017 20:22:01 +0000 (12:22 -0800)]
i40e: Clean up handling of private flags
This patch cleans up and addresses several issues in the way that i40e
handles private flags. Previously the code was choosing fixed bits and
trying to match them up with strings in a somewhat haphazard way. This
resulted in the possibility for adding a new bit and causing a mismatch as
the private flags are linear bits starting at 0, and the private flags in
the driver were split up over a group specific to the PF and a group that
was global.
What this change does is define an array of structs used to represent the
private flags. Contained within the structs are the bits necessary to know
which flags to set and/or clear depending on the state of the bit. By
doing this we can add new bits in the future with minimal overhead and
avoid creating possible mis-matches should we need to remove a flag based
on compile options.
Change-ID: Ia3214ab04f0ab2f70354ac0997a135f1d01b0acd Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit aca955d831a644dc1dc22b60b30ff669567580f9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Preethi Banala [Fri, 10 Mar 2017 20:22:00 +0000 (12:22 -0800)]
i40evf: enforce descriptor write-back mechanism for VF
The current driver mode is to use a write-back mechanism for the head
register which indicates transmit completions. The VF driver needs to be
able to work on hardware that exclusively uses descriptor write-back, so
change the default driver mode of operation to descriptor write-back for
VF. In our analysis, performance wasn't significantly different with
either write-back method.
Change-ID: Ia92e4ec77c2df8dc4515c71d53746d57d77759af Signed-off-by: Preethi Banala <preethi.banala@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b1cb07db6e2b3c982ec858b06d42d24c7e267fdc) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 20 Mar 2017 23:45:35 +0000 (16:45 -0700)]
i40e: initialize params before notifying of l2_param_changes
Probably due to some mis-merging fix a bug associated with commits d7ce6422d6e6 ("i40e: don't check params until after checking for client
instance", 2017-02-09) and 3140aa9a78c9 ("i40e: KISS the client
interface", 2017-03-14)
The first commit tried to move the initialization of the params
structure so that we didn't bother doing this if we didn't have a client
interface. You can already see that it looks fishy because of the
indentation. The second commit refactors a bunch of the interface, and
incorrectly drops the params initialization.
I believe what occurred is that internally the two patches were
re-ordered, and the merge conflicts as a result were performed
incorrectly.
Fix the use of an uninitialized variable by correctly initializing the
params variable via i40e_client_get_params().
Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7be147dc143a9a0030a3881870425cae03e5dbff) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alexander Duyck [Tue, 21 Feb 2017 23:55:46 +0000 (15:55 -0800)]
i40e/i40evf: Clean-up process_skb_fields
This is a minor clean-up to make the i40e/i40evf process_skb_fields
function look a little more like what we have in igb. The Rx checksum
function called out a need for skb->protocol but I can't see where it
actually needs it. I am assuming this is something that was likely
refactored out some time ago as the Rx checksum code has gone through a few
rewrites.
Change-ID: I0b4668a34d90b61b66ded7c7c26e19a3e2d06251 Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit a5b268e4b103e5dea4850ad732b6ed584a5562ea) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 21 Feb 2017 23:55:45 +0000 (15:55 -0800)]
i40e: removed no longer needed delays
Removed no longer needed delays. At preproduction stage those delays were
needed but now these delays are not needed.
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 0a25b7311d856c31dea2a4e92bf88982026d2afb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Robert Konklewski [Tue, 21 Feb 2017 23:55:42 +0000 (15:55 -0800)]
i40e: Fixed race conditions in VF reset
First, this patch eliminates IOMMU DMAR Faults caused by VF hardware.
This is done by enabling VF hardware only after VSI resources are
freed. Otherwise, hardware could DMA into memory that is (or just has
been) being freed.
Then, the VF driver is activated only after VSI resources have been
reallocated. That's because the VF driver can request resources
immediately after it's activated. So they need to be ready at that
point.
The second race condition happens when the OS initiates a VF reset,
and then before it's finished modifies VF's settings by changing its
MAC, VLAN ID, bandwidth allocation, anti-spoof checking, etc. These
functions needed to be blocked while VF is undergoing reset. Otherwise,
they could operate on data structures that had just been freed or not
yet fully initialized.
Change-ID: I43ba5a7ae2c9a1cce3911611ffc4598ae33ae3ff Signed-off-by: Robert Konklewski <robertx.konklewski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit beff3e9d80138e332ca08d909e1648e82764dc0c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alexander Duyck [Tue, 21 Feb 2017 23:55:41 +0000 (15:55 -0800)]
i40e/i40evf: Fix use after free in Rx cleanup path
We need to reset skb back to NULL when we have freed it in the Rx cleanup
path. I found one spot where this wasn't occurring so this patch fixes it.
Change-ID: Iaca68934200732cd4a63eb0bd83b539c95f8c4dd Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 741b8b832a57402380be79d7d11a59eaf57fff3b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Harshitha Ramamurthy [Tue, 21 Feb 2017 23:55:40 +0000 (15:55 -0800)]
i40e: fix configuration of RSS table with DCB
There exists a bug in the driver where the calculation of the
RSS size was not taking into account the number of traffic classes
enabled. This patch factors in the traffic classes both in
the initial configuration of the table as well as reconfiguration.
Change-ID: I34dcd345ce52faf1d6b9614bea28d450cfd5f621 Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit f25571b576c72f4bfa8b0766b4d582ee9662bcbf) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alexander Duyck [Fri, 24 Mar 2017 22:01:42 +0000 (15:01 -0700)]
i40e: Do not enable NAPI on q_vectors that have no rings
When testing the epoll w/ busy poll code I found that I could get into a
state where the i40e driver had q_vectors w/ active NAPI that had no rings.
This was resulting in a divide by zero error. To correct it I am updating
the driver code so that we only support NAPI on q_vectors that have 1 or
more rings allocated to them.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Orabug: 26132523
(cherry picked from commit 13a8cd191a2b470cfd435b3b57dbd21aa65ff78c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Tue, 7 Mar 2017 23:17:52 +0000 (15:17 -0800)]
i40e: make use of hlist_for_each_entry_continue
Replace a complex if->continue->else->break construction in
i40e_next_filter. We can simply use hlist_for_each_entry_continue
instead. This drops a lot of confusing code. The resulting code is much
easier to understand the intention, and follows the more normal pattern
for using hlist loops. We could have also used a break with a "return
next" at the end of the function, instead of return NULL, but the
current implementation is explicitly clear that when you reach the end
of the loop you get a NULL value. The alternative construction is less
clear since the reader would have to know that next is NULL at the end
of the loop.
Change-Id: Ife74ca451dd79d7f0d93c672bd42092d324d4a03 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 584a88709bf4880ba5f8fed72da50512fbd9bdbb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:52 +0000 (14:38 -0800)]
i40e: document drivers use of ntuple filters
Add documentation describing the drivers use of ethtool ntuple filters,
including the limitations that it has due to hardware, as well as how it
reads and parses the user-def data block.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 55877012d5588ce7427919d6b869922f1a5f60bc) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:51 +0000 (14:38 -0800)]
i40e: add support for SCTPv4 FDir filters
Enable FDir filters for SCTPv4 packets using the ethtool ntuple
interface to enable filters. The ethtool API does not allow masking on
the verification tag.
Change-Id: I093e88a8143994c7e6f4b7b17a0bd5cf861d18e4 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit f223c8752a0b756b82ad8f077172054548a6d644) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:50 +0000 (14:38 -0800)]
i40e: implement support for flexible word payload
Add support for flexible payloads passed via ethtool user-def field.
This support is somewhat limited due to hardware design. The input set
can only be programmed once per filter type, and the flexible offset is
part of this filter input set. This means that the user cannot program
both a regular and a flexible filter at the same time for a given flow
type. Additionally, the user may not program two flexible filters of the
same flow type with different offsets, although they are allowed to
configure different values at that offset location.
We support a single flexible word (2byte) value per protocol type, and
we handle the FLX_PIT register using a list of flexible entries so that
each flow type may be configured separately.
Due to hardware implementation, the flexible data is offset from the
start of the packet payload, and thus may not be in part of the header
data. For this reason, the offset provided by the user defined data is
interpreted as a byte offset from the start of the matching payload.
Previous implementations have tried to represent the offset as from the
start of the frame, but this is not feasible because header sizes may
change due to options.
Change-Id: 36ed27995e97de63f9aea5ade5778ff038d6f811 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 0e588de17f086c32432d6ca7f4053b37c6fc487c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:49 +0000 (14:38 -0800)]
i40e: add parsing of flexible filter fields from userdef
Add code to parse the user-def field into a data structure format. This
code is intended to allow future extensions of the user-def field by
keeping all code that actually reads and writes the field into a single
location. This ensures that we do not litter the driver with references
to the user-def field and minimizes the amount of bitwise operations we
need to do on the data.
Add code which parses the lower 32bits into a flexible word and its
offset. This will be used in a future patch to enable flexible filters
which can match on some arbitrary data in the packet payload. For now,
we just return -EOPNOTSUPP when this is used.
Add code to fill in the user-def field when reporting the filter back,
even though we don't actually implement any user-def fields yet.
Additionally, ensure that we mask the extended FLOW_EXT bit from the
flow_type now that we will be accepting filters which have the FLOW_EXT
bit set (and thus make use of the user-def field).
Change-Id: I238845035c179380a347baa8db8223304f5f6dd7 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e793095e8a576836da96ec6fc1d6064328d95929) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:48 +0000 (14:38 -0800)]
i40e: partition the ring_cookie to get VF index
Do not use the user-def field for determining the VF target. Instead,
similar to ixgbe, partition the ring_cookie value into 8bits of VF
index, along with 32bits of queue number. This is better than using the
user-def field, because it leaves the field open for extension in
a future patch which will enable flexible data. Also, this matches with
convention used by ixgbe and other drivers.
Change-Id: Ie36745186d817216b12f0313b99ec95cb8a9130c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 43b15697a3993bf24b0190bccec369d314bc8c36) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:47 +0000 (14:38 -0800)]
i40e: allow changing input set for ntuple filters
Add support to detect when we can update the input set for each flow
type.
Because the hardware only supports a single input set for all flows of
that matching type, the driver shall only allow the input set to change
if there are no other configured filters for that flow type.
Thus, the first filter added for each flow type is allowed to change the
input set, and all future filters must match the same input set. Display
a diagnostic message whenever the filter input set changes, and
a warning whenever a filter cannot be accepted because it does not match
the configured input set.
Change-Id: Ic22e1c267ae37518bb036aca4a5694681449f283 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9229e9933471faf211e42bb56b8101621c489841) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:46 +0000 (14:38 -0800)]
i40e: restore default input set for each flow type
Ensure that the default input set is correctly reprogrammed when
cleaning up after disabling flow director support. This ensures that the
programmed value will be in a clean state.
Although we do not yet have support for SCTPv4 filters, a future patch
will add support for this protocol, so we will correctly restore the
SCTPv4 input set here as well. Note that strictly speaking the default
hardware value for SCTP includes matching the verification tag. However,
the ethtool API does not have support for specifying this value, so
there is no reason to keep the verification field enabled.
This patch is the next step on the way to enabling partial tuple filters
which will be implemented in a following patch.
Change-Id: Ic22e1c267ae37518bb036aca4a5694681449f283 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3bcee1e653c1c1d78485cc7a298b392675a1a56d) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Tue, 7 Mar 2017 23:05:23 +0000 (15:05 -0800)]
i40e: check current configured input set when adding ntuple filters
Do not assume that hardware has been programmed with the default mask,
but instead read the input set registers to determine what is currently
programmed. This ensures that all programmed filters match exactly how
the hardware will interpret them, avoiding confusion regarding filter
behavior.
This sets the initial ground-work for allowing custom input sets where
some fields are disabled. A future patch will fully implement this
feature.
Instead of using bitwise negation, we'll just explicitly check for the
correct value. The use of htonl and htons are used to silence sparse
warnings. The compiler should be able to handle the constant value and
avoid actually performing a byteswap.
Change-Id: I3d8db46cb28ea0afdaac8c5b31a2bfb90e3a4102 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 36777d9fa24c1b823f6b4dc3b1ecf9078f182515) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Tue, 7 Mar 2017 23:05:22 +0000 (15:05 -0800)]
i40e: correctly honor the mask fields for ETHTOOL_SRXCLSRLINS
The current implementation of .set_rxnfc does not properly read the mask
field for filter entries. This results in incorrect driver behavior, as
we do not reject filters which have masks set to ignore some fields. The
current implementation simply assumes that every part of the tuple or
"input set" is specified. This results in filters not behaving as
expected, and not working correctly.
As a first step in supporting some partial filters, add code which
checks the mask fields and rejects any filters which do not have an
acceptable mask. For now, we just assume that all fields must be set.
This will get the driver one step towards allowing some partial filters.
At a minimum, the ethtool commands which previously installed filters
that would not function will now return a non-zero exit code indicating
failure instead.
We should now be meeting the minimum requirements of the .set_rxnfc API,
by ensuring that all filters we program have a valid mask value for each
field.
Finally, add code to report the mask correctly so that the ethtool
command properly reports the mask to the user.
Note that the typecast to (__be16) when checking source and destination
port masks is required because the ~ bitwise negation operator does not
correctly handle variables other than integer size.
Change-Id: Ia020149e07c87aa3fcec7b2283621b887ef0546f Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit faa16e0f384885e1e13a3e28e688347bf5456a8e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:39:13 +0000 (14:39 -0800)]
i40e: always remove old filter when adding new FDir filter
The previous code relied on i40e_match_fdir_input_set to determine when
determining whether to free the old filter. Change this code so that we
simply unconditionally delete the old filter, even if it's identical to
the new filter. This ensures that we don't leak any memory, and that we
always update the filters as expected.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit c6da525de724e3fbe439b8dad385395bb4fd2211) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:39:12 +0000 (14:39 -0800)]
i40e: explicitly fail on extended MAC field for ethtool_rx_flow_spec
Although we will fail the filter later due to checking flow_type which
will have a bogus invalid type, it is possible future refactoring will
remove this hidden failure case. Avoid a possible issue in the future by
explicitly checking the flow type at the start.
Change-Id: Ia98eb26f7b93ccbe38c7141e8f203ef496fc6598 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 1ec8deac8c63505194e773b9657824ed3c2fbdd8) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:46 +0000 (14:38 -0800)]
i40e: add counters for UDP/IPv4 and IPv4 filters
In preparation for adding code to properly check the mask values, we
will need to know the number of active filters for each type. Add
counters for each filter type. Rename the already existing fd_tcp_rule
to fd_tcp4_filter_cnt to match the style of other names. To avoid style
warnings, avoid assigning multiple parameters at once, and fix up one
other case where we did so previously.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 097dbf52505962d06f9b707a3984d48d4f25fbe9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:45 +0000 (14:38 -0800)]
i40e: don't re-enable ATR when flushing filters if SB has TCP4/IPv4 rules
When flushing and replaying FDIR filters, it is possible we would
disable ATR, and then re-enable it even though we should have kept
it disabled due to existing TCP/IPv4 filters. Fix this by checking
whether we have TCP4/IPv4 filters before re-enabling.
Alternatively, we could instead restore ATR and then replay filters,
however, this would cause us to rapidly enable and then disable ATR in
some cases.
Change-ID: I076e4cc1e4409bce7f98f3c213295433a4ff43d8 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Avinash Dayanand <avinash.dayanand@intel.com> Reviewed-by: Alan Brady <alan.brady@intel.com> Reviewed-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 510dd4609f581329a421fa20e1b802b629bb7ee2) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:44 +0000 (14:38 -0800)]
i40e: reset fd_tcp_rule count when restoring filters
Since we're about to reprogram the filters, we need to ensure that the
fd_tcp_rule count is correctly reset to 0. Otherwise, we will keep
a stale count that does not accurately reflect the number of programmed
TCPv4 filters.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 6d069425f0fcafff5bfdd292e5f345ce55d46a43) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:43 +0000 (14:38 -0800)]
i40e: remove redundant check for fd_tcp_rule when restoring filters
i40e_fdir_filter_restore re-adds all existing filters, which already
checks when adding a TCPv4 filter to disable ATR. We don't need to make
the check twice, so remove this redundant code.
Change-ID: Ia0b0690e23523915199d601494557def135c9d7f Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e122eb7482d4af67bec77055ca2a9009867491e9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:42 +0000 (14:38 -0800)]
i40e: exit ATR mode only when adding TCP/IPv4 filter succeeds
Move ATR exit check after we have sent the TCP/IPv4 filter to the ring
successfully. This avoids an issue where we potentially update the
filter count without actually succeeding in adding the filter. Now, we
only increment the fd_tcp_rule after we've succeeded. Additionally, we
will re-enable ATR mode only after deletion of the filter is actually
posted to the FDIR ring.
Change-ID: If5c1dea422081cc5e2de65618b01b4c3bf6bd586 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 377cc24980588d03abf3a2a843b8c53dfc8b5a1b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:41 +0000 (14:38 -0800)]
i40e: return immediately when failing to add fdir filter
Instead of setting err=true and checking this to determine when to free
the raw_packet near the end of the function, simply kfree and return
immediately. The resulting code is a bit cleaner and has one less
variable. This also resolves a subtle bug in the ipv4 case which could
fail to add the first filter and then never free the memory, resulting
in a small memory leak.
Change-ID: I7583aac033481dc794b4acaa14445059c8930ff1 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Avinash Dayanand <avinash.dayanand@intel.com> Reviewed-by: Alan Brady <alan.brady@intel.com> Reviewed-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e5187ee3ee9a95b1aa32a9a3daf4f07a9f89c20c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:40 +0000 (14:38 -0800)]
i40e: rework exit flow of i40e_add_fdir_ethtool
Refactor the exit flow of the i40e_add_fdir_ethtool function. Move the
input_label to the end of the function, removing the dependency on
having a non-zero return value. Add a comment explaining why it is ok
not to free the fdir data structure, because the structure is now stored
in the fdir_filter_list.
Change-Id: I723342181d59cd0c9f3b31140c37961ba37bb242 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 01016da1e58136518252822738fe833c662df916) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:39 +0000 (14:38 -0800)]
i40e: don't use arrays for (src|dst)_ip
The code originally included src_ip and dst_ip with enough space to
support ipv6 filters. However, no actual support for ipv6 filters has
been implemented. Thus, remove the arrays and just use __be32 values.
Should ipv6 support be added in the future, we can replace these with
a union that has sizes for both values.
Change-Id: I1bc04032244a80eb6ebc8a4e6c723a4a665c1dd5 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 8ce43dce6f272202dcd127e0e288b37277ca87dd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 6 Feb 2017 22:38:38 +0000 (14:38 -0800)]
i40e: send correct port number to AdminQ when enabling UDP tunnels
The firmware expects the port numbers for offloaded UDP tunnels in
Little Endian format. We accidentally sent the value in Big Endian
format which obviously will cause the wrong port number to be put into
the UDP tunnels list. This results in VxLAN and Geneve tunnel Rx
offloads being essentially disabled, unless the port number happens to
be identical after byte swapping. Note that i40e_aq_add_udp_tunnel()
will byteswap the parameter from host order into Little Endian so we
don't need worry about passing strictly a __le16 value to the command.
This patch essentially reverts b3f5c7bc88ba ("i40e: Fix for extra byte
swap in tunnel setup", 2016-08-24), but in a way that makes the result
much more clear to the reader.
Fixes: b3f5c7bc88ba ("i40e: Fix for extra byte swap in tunnel setup", 2016-08-24) Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Williams, Mitch A <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit fe0b0cd97b4f210ecd1693edba6eec10820e11f2) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Harshitha Ramamurthy [Fri, 3 Feb 2017 18:57:42 +0000 (10:57 -0800)]
i40e: rename auto_disable_flags to hw_disabled_flags
A previous commit introduced a field that tracks the features
that are disabled due to HW resource limitations as opposed
to the featured disabled by the user. This patch changes the
name of the field to make it more readable since it might get
confusing when looking at code containing both the flags
field and the auto_disable_features field together.
Change-ID: Idcc9888659698f6fe3ccff17c8c3f09b5026f708 Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b77ac975930741f0b6612b18e55d7a72c81ea2ac) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Mon, 30 Jan 2017 20:29:37 +0000 (12:29 -0800)]
i40e/i40evf: Change version from 1.6.27 to 2.1.7
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>
Orabug: 26132523
(cherry picked from commit 15990832cd3e7e8904f8dacdabfa33adb9a836d6) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Mon, 30 Jan 2017 20:29:36 +0000 (12:29 -0800)]
i40e: Allow untrusted VFs to have more filters
Our original filter limit of 8 was based on behavior that we saw from
Linux VMs. Now we're running Other Operating Systems under KVM and we
see that they commonly use more MAC filters. Since it seems weird to
require people to enable trusted VFs just to boot their OS, bump the
number of filters allowed by default.
Change-ID: I76b2dcb2ad6017e39231ad3096c3fb6f065eef5e Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 4dbc56613962bfa597c345d8eff839870293c0a5) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Filip Sadowski [Mon, 30 Jan 2017 20:29:34 +0000 (12:29 -0800)]
i40e: Clarify steps in MAC/VLAN filters initialization routine
This patch clarifies the reason for removal of automatically
firmware-generated filter and explicit addition of filter which
accepts frames with any VLAN id.
Change-ID: Iabf180b6d61c4d8a36d3bcf8457c377a6f2aca0e Signed-off-by: Filip Sadowski <filip.sadowski@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3954b39102677c879d7663621fb9a7e0da349274) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Lihong Yang [Mon, 30 Jan 2017 20:29:33 +0000 (12:29 -0800)]
i40e: fix RSS queues only operating on PF0
This patch fixes the issue that RSS offloading only works on PF0 by
using the direct register writing of the hash keys for the VFs instead
of using the admin queue command to do so.
Change-ID: Ia02cda7dbaa23def342e8786097a2c03db6f580b Signed-off-by: Lihong Yang <lihong.yang@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 26f77e53cfee2b1b066071353be03988897e23c3) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Lihong Yang [Mon, 30 Jan 2017 20:29:32 +0000 (12:29 -0800)]
i40e: fix ethtool to get EEPROM data from X722 interface
Currently ethtool -e will error out with a X722 interface
as its EEPROM has a scope limit at offset 0x5B9FFF.
This patch fixes the issue by setting the EEPROM length to
the scope limit to avoid NVM read failure beyond that.
Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372 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>
Orabug: 26132523
(cherry picked from commit c271dd6c391b535226cf1a81aaad9f33cb5899d3) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Tue, 24 Jan 2017 18:24:01 +0000 (10:24 -0800)]
i40e: don't add more vectors to num_lan_msix than number of CPUs
This is a solution to avoid adding too many queues to num_lan_msix.
A recent refactor of queue pairs accidentally added all remaining
vectors to the num_lan_msix which can have adverse performance issues,
due to enabling more queues than the number of CPU cores.
This patch removes the old calculation, and replaces it with a simple
algorithm.
1) add queue pairs up to num_online_cpus(), but capped at half of total
vectors
2) then add alternative features such as flow directory and similar
3) finally, add the remaining vectors back to queue pairs, but capped
such that the total number of queue pairs does not exceed
num_online_cpus().
Change-ID: I668abf67d5011a1248866daba8885f4ff00cb8d9 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit c0cf70a6fc373570f86c6dc4799d775363b9946e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Tue, 24 Jan 2017 18:24:00 +0000 (10:24 -0800)]
i40e: KISS the client interface
(KISS is Keep It Simple, Stupid. Or is it?)
The client interface vastly overengineered for what it needs to do.
It was originally designed to support multiple clients on multiple
netdevs, possibly even with multiple drivers. None of this happened,
and now we know that there will only ever be one client for i40e
(i40iw) and one for i40evf (i40iwvf). So, time for some KISS. Since
i40e and i40evf are a Dynasty, we'll simplify this one to match the
VF interface.
First, be a Destroyer and remove all of the lists and locks required
to support multiple clients. Keep one static around to keep track of
one client, and track the client instances for each netdev in the
driver's pf (or adapter) struct. Now it's Almost Human.
Since we already know the client type is iWarp, get rid of any checks
for this. Same for VSI type - it's always going to be the same type,
so it's just a Parasite.
While we're at it, fix up some comments. This makes the function
headers actually match the functions.
These changes reduce code complexity, simplify maintenance,
squash some lurking timing bugs, and allow us to Rock and Roll All
Nite.
Change-ID: I1ea79948ad73b8685272451440a34507f9a9012e Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 0ef2d5afb12d379f4dd5df696219a01b88bb778a)
Conflict resolved:
drivers/net/ethernet/intel/i40e/i40e_main.c Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Shannon Nelson [Tue, 24 Jan 2017 18:23:58 +0000 (10:23 -0800)]
i40e: fix up recent proxy and wol bits for X722_SUPPORT
Some opcodes added & reordered to be in numerical order with the
rest of the opcodes.
This patch adds admin queue structs to support Wake on LAN feature
for X722.
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d60be2ca9c42e127702a8fd556d696b101f3c09b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Aaron Salter [Fri, 2 Dec 2016 20:33:02 +0000 (12:33 -0800)]
i40e: Acquire NVM lock before reads on all devices
Acquire NVM lock before reads on all devices. Previously, locks were
only used for X722 and later. Fixes an issue where simultaneous X710
NVM accesses were interfering with each other.
Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638 Signed-off-by: Aaron Salter <aaron.k.salter@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 96a39aed25e6559b160786117df124084feb9080) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Masahiro Yamada [Mon, 27 Feb 2017 22:29:06 +0000 (14:29 -0800)]
scripts/spelling.txt: add "varible" pattern and fix typo instances
Fix typos and add the following to the scripts/spelling.txt:
varible||variable
While we are here, tidy up the comment blocks that fit in a single line
for drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c and
net/sctp/transport.c.
Benjamin Poirier [Fri, 13 Jan 2017 01:04:14 +0000 (17:04 -0800)]
i40e: Invoke softirqs after napi_reschedule
The following message is logged from time to time when using i40e:
NOHZ: local_softirq_pending 08
i40e may schedule napi from a workqueue. Afterwards, softirqs are not run
in a deterministic time frame. The problem is the same as what was
described in commit ec13ee80145c ("virtio_net: invoke softirqs after
__napi_schedule") and this patch applies the same fix to i40e.
Signed-off-by: Benjamin Poirier <bpoirier@suse.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 83a0c6e589017ce737720b9e05e2fa3fe4f7b860) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Carolyn Wyborny [Wed, 21 Dec 2016 23:04:47 +0000 (18:04 -0500)]
i40e: remove duplicate device id from PCI table
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit ee847d935156b041679ad82c269796dae1afaa6b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:17 +0000 (15:44 -0800)]
i40e: mark the value passed to csum_replace_by_diff as __wsum
Fix, or rather, avoid a sparse warning caused by the fact that
csum_replace_by_diff expects to receive a __wsum value. Since the
calculation appears to work, simply typecast the passed paylen value to
__wsum to avoid the warning.
This seems pretty fishy since __wsum was obviously annotated as
a separate type on purpose, so this throws the entire calculation into
question. Since it currently appears to behave as expected, the typecast
is probably safe.
Change-ID: I4fdc5cddd589abc16098176e8a61127e761488f4 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b9c015d421946fe3675fcb9cbacd0a37f1d3263c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Harshitha Ramamurthy [Mon, 12 Dec 2016 23:44:16 +0000 (15:44 -0800)]
i40e: Error handling for link event
There exists an intermittent bug which causes the 'Link Detected'
field reported by the 'ethtool <iface>' command to be 'Yes' when
in fact, there is no link. This patch fixes the problem by
enabling temporary link polling when i40e_get_link_status returns
an error. This causes the driver to remember that an admin queue
command failed and polls, until the function returns with a success.
Change-Id: I64c69b008db4017b8729f3fc27b8f65c8fe2eaa0 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>
Orabug: 26132523
(cherry picked from commit ae13670824d5adadc95a881ebfaa6fa8735218f0) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:15 +0000 (15:44 -0800)]
i40e: properly convert le16 value to CPU format
This ensures that the pvid which is stored in __le16 format is converted
to the CPU format. This will fix comparison issues on Big Endian
platforms.
Change-ID: I92c80d1315dc2a0f9f095d5a0c48d461beb052ed Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 5cb259016b4258d7ac53588a01d17da1ceda84b7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:14 +0000 (15:44 -0800)]
i40e: convert to cpu from le16 to generate switch_id correctly
On Big Endian platforms we would incorrectly calculate the wrong switch
id since we did not properly convert the le16 value into CPU format.
Caught by sparse.
Change-ID: I69a2f9fa064a0a91691f7d0e6fcc206adceb8e36 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 2ae0bf501425cbddc8b992a2b65fc04d911cae8c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Mon, 12 Dec 2016 23:44:13 +0000 (15:44 -0800)]
i40e: refactor AQ CMD buffer debug printing
This patch refactors the '%*ph' printk format specifier to instead use
the print_hex_dump function, as recommended by the '%*ph' documentation.
This produces better/more standardized output.
Change-ID: Id56700b4e8abc40ff8c04bc8379e7df04cb4d6fd Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 773d4023badee2e196f4125a94fe9d5a739720a0) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Carolyn Wyborny [Mon, 12 Dec 2016 23:44:12 +0000 (15:44 -0800)]
i40e: Fix Adaptive ITR enabling
This patch fixes a bug introduced with the addition of the per queue
ITR feature support in ethtool. With that addition, there were
functions added which converted the ITR settings to binary values.
The IS_ENABLED macros that run on those values check whether a bit
is set or not and with the value being binary, the bit check always
returned ITR disabled which prevents any updating of the ITR rate.
This patch fixes the problem by changing the functions to return the
current ITR value instead and renaming it to better reflect
its function. These functions now provide a value which will be
accurately asessed and update the ITR as intended.
Change-ID: I14f1d088d052e27f652aaa3113e186415ddea1fc Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3c234c4709529298498b597bcff35f56ac866a99) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Mon, 12 Dec 2016 23:44:11 +0000 (15:44 -0800)]
i40evf: add comment
Add a comment to reduce confusion.
Change-ID: I3d5819c0f3f5174680442ae54398a073d4a61f4f Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 51f38262669b88b6f5ec52cb93dc72c58d85dc1f) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Mon, 12 Dec 2016 23:44:10 +0000 (15:44 -0800)]
i40evf: free rings in remove function
When the i40evf_remove() calls netdev close, the device doesn't actually
close - it schedules the work for the watchdog to perform. Since we're
stopping the watchdog, this work doesn't get done. However, we're
resetting the part, so we can free resources after the reset request has
gone through. This plugs a memory leak.
Change-ID: Id5335dcaf76ce00d2a4c3d26e9faf711d7f051cf Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 8a68badd12a8b708a02d54cd5aac4d07851a6d5a) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Mon, 12 Dec 2016 23:44:09 +0000 (15:44 -0800)]
i40e: remove unnecessary call to i40e_update_link_info
This call is made just prior to running i40e_link_event. In
i40e_link_event, we set hw->phy.get_link_info to true just prior to
calling i40e_get_link_status, which conveniently runs
i40e_update_link_info for us. Thus, we are running i40e_update_link_info
twice, which seems like something we don't need to do...
Change-ID: I36467a570f44b7546d218c99e134ff97c2709315 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 03aa268b146127361c206fe3942add2adf6ce1d7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Joshua Hay [Mon, 12 Dec 2016 23:44:08 +0000 (15:44 -0800)]
i40e: enable mc magic pkt wakeup during power down
This patch adds a call to the mac_address_write admin q function during
power down to update the PRTPM_SAH/SAL registers with the MC_MAG_EN bit
thus enabling multicast magic packet wakeup.
A FW workaround is needed to write the multicast magic wake up enable
bit in the PRTPM_SAH register. The FW expects the mac address write
admin q cmd to be called first with one of the WRITE_TYPE_LAA flags
and then with the multicast relevant flags.
*Note: This solution only works for X722 devices currently. A PFR will
clear the previously mentioned bit by default, but X722 has support for a
WOL_PRESERVE_ON_PFR flag which prevents the bit from being cleared. Once
other devices support this flag, this solution should work as well.
Change-ID: I51bd5b8535bd9051c2676e27c999c1657f786827 Signed-off-by: Joshua Hay <joshua.a.hay@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 1d68005db4e72082f3e537d6c0cf831a71a7e2ee) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Alan Brady [Mon, 12 Dec 2016 23:44:07 +0000 (15:44 -0800)]
i40e: fix disable overflow promiscuous mode
There exists a bug in which the driver is unable to exit overflow
promiscuous mode after having added "too many" mac filters. It is
expected that after triggering overflow promiscuous, removing the
failed/extra filters should then disable overflow promiscuous mode.
The bug exists because we were intentionally skipping the sync_vsi_filter
path in cases where we were removing failed filters since they shouldn't
have been added to the firmware in the first place, however we still
need to go through the sync_vsi_filter code path to determine whether or
not it is ok to exit overflow promiscuous mode. This patch fixes the
bug by making sure we go through the sync_vsi_filter path in cases of
failed filters.
Change-ID: I634d249ca3e5fa50729553137c295e73e7722143 Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit a410c821c0cf50bc0b73a91435852cd04b2c7acd) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Henry Tieman [Fri, 2 Dec 2016 20:33:01 +0000 (12:33 -0800)]
i40e: Save more link abilities when using ethtool
Ethtool support needs to save more PHY information. The
added information includes FEC capabilities and 25G link
types. Without this change it is possible to lose 25G or
FEC settings by using ethtool.
Change-ID: Ie42255b1e901ffbf9583b8c46466a54894114280 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>
Orabug: 26132523
(cherry picked from commit b7eaf8f16e87c3896e9b8c0b2e54d71210d43b48) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:33:00 +0000 (12:33 -0800)]
i40e: avoid race condition when sending filters to firmware for addition
Refactor how we add new filters to firmware to avoid a race condition
that can occur due to removing filters from the hash temporarily.
To understand the race condition, suppose that you have a number of MAC
filters, but have not yet added any VLANs. Now, add two VLANs in rapid
succession. A possible resulting flow would look something like the
following:
(1) lock hash for add VLAN
(2) add the new MAC/VLAN combos for each current MAC filter
(3) unlock hash
(4) lock hash for filter sync
(5) notice that we have a VLAN, so prepare to update all MAC filters
with VLAN=-1 to be VLAN=0.
(6) move NEW and REMOVE filters to temporary list
(7) unlock hash
(8) lock hash for add VLAN
(9) add new MAC/VLAN combos. Notice that no MAC filters are currently in
the hash list, so we don't add any VLANs <--- BUG!
(10) unlock hash
(11) sync the temporary lists to firmware
(12) lock hash for post-sync
(13) move the temporary elements back to the main list
....
Because we take filters out of the main hash into temporary lists, we
introduce a narrow window where it is possible that other callers to the
list will not see some of the filters which were previously added but
have not yet been finalized. This results in sometimes dropping VLAN
additions, and could also result in failing to add a MAC address on the
newly added VLAN.
One obvious way to avoid this race condition would be to lock the entire
firmware process. Unfortunately this does not work because adminq
firmware commands take a mutex which results in a sleep while atomic
BUG(). So, we can't use the simplest approach.
An alternative approach is to simply not remove the filters from the
hash list while adding. Instead, add an i40e_new_mac_filter structure
which we will use to track added filters. This avoids the need to remove
the filter from the hash list. We'll store a pointer to the original
i40e_mac_filter, along with our own copy of the state.
We won't update the state directly, so as to avoid race with other code
that may modify the state while under the lock. We are safe to read
f->macaddr and f->vlan since these only change in two locations. The
first is on filter creation, which must have already occurred. The
second is inside i40e_correct_vlan_filters which was previously run
after creation of this object and can't be run again until after. Thus,
we should be safe to read the MAC address and VLAN while outside the
lock.
We also aren't going to run into a use-after-free issue because the only
place where we free filters is when they are marked FAILED or when we
remove them inside the sync subtask. Since the subtask has its own
critical flag to prevent duplicate runs, we know this won't happen. We
also know that the only location to transition a filter from NEW to
FAILED is inside the subtask also, so we aren't worried about that
either.
Use the wrapper i40e_new_mac_filter for additions, and once we've
finalized the addition to firmware, we will update the filter state
inside a lock, and then free the wrapper structure.
In order to avoid a possible race condition with filter deletion, we
won't update the original filter state unless it is still
I40E_FILTER_NEW when we finish the firmware sync.
This approach is more complex, but avoids race conditions related to
filters being temporarily removed from the list. We do not need the same
behavior for deletion because we always unconditionally removed the
filters from the list regardless of the firmware status.
Change-Id: I14b74bc2301f8e69433fbe77ebca532db20c5317 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 671889e6740ac7ab84d1420525b50d1d47001102) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:32:59 +0000 (12:32 -0800)]
i40e: allow i40e_update_filter_state to skip broadcast filters
Fix a bug where we modified the mac_filter_hash while outside a lock,
when handling addition of broadcast filters.
Normally, we add filters to firmware by batching the additions into
lists and issuing 1 update for every few filters. Broadcast filters are
handled differently, by instead setting the broadcast promiscuous mode
flags. In order to make sure the 1<->1 mapping of filters in our
addition array lined up with filters in the hlist tmp_add_list, we had
to remove the filter and move it back to the main hash. However, we
didn't do this under lock, which could cause consistency problems for
the list.
Fix this by updating i40e_update_filter_state logic so that it knows to
avoid broadcast filters. This ensures that we don't have to remove the
filter separately, and can put it back using the normal flow.
Change-ID: Id288fade80b3e3a9a54b68cc249188cb95147518 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d88d40b01c5c0dad6a1dca3b18267849eef4a2a9) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 2 Dec 2016 20:32:58 +0000 (12:32 -0800)]
i40e: don't warn every time we clear an Rx timestamp register
The intent of this message was to indicate to a user that we might have
missed a timestamp event for a valid packet. The original method of
detecting the missed events relied on waiting until all 4 registers were
filled.
A recent commit d55458c0cd7a5 ("i40e: replace PTP Rx timestamp hang
logic") replaced this logic with much better detection
scheme that could detect a stalled Rx timestamp register even when other
registers were still functional.
The new logic means that a message will be displayed almost as soon as
a timestamp for a dropped frame occurs. This new logic highlights that
the hardware will attempt timestamp for frames which it later decides to
drop. The most prominent example is when a multicast PTP frame is
received on a multicast address that we are not subscribed to.
Because the hardware initiates the Rx timestamp as soon as possible, it
will latch an RXTIME register, but then drop the packet.
This results in users being confused by the message as they are not
expecting to see dropped timestamp messages unless their application
also indicates that timestamps were missing.
Resolve this by reducing the severity and frequency of the displayed
message. We now only print the message if 3 or 4 of the RXTIME registers
are stalled and get cleared within the same watchdog event. This ensures
that the common case does not constantly display the message.
Additionally, since the message is likely not as meaningful to most
users, reduce the message to a dev_dbg instead of a dev_warn.
Users can still get a count of the number of timestamps dropped by
reading the ethtool statistics value, if necessary.
Change-ID: I35494442226a444c418dfb4f91a3070d06c8435c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e6e3fc2bd3ee03117e1ce388c897fc3b2da97d65) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Henry Tieman [Fri, 2 Dec 2016 20:32:57 +0000 (12:32 -0800)]
i40e: Save link FEC info from link up event
Store the FEC status bits from the link up event into the
hw_link_info structure.
Change-ID: I9a7b256f6dfb0dce89c2f503075d0d383526832e 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>
Orabug: 26132523
(cherry picked from commit 3e03d7ccf4418c87a134bbfa79c05090296767f7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Sudheer Mogilappagari [Fri, 10 Feb 2017 07:58:22 +0000 (23:58 -0800)]
i40e: Add bus number info to i40e_bus_info struct
Currently i40e_bus_info has PCI device and function info only and log
messages print device number as bus number. Added field to provide bus
number info and modified log statements to print bus, device and
function information.
Change-ID: I811617cee2714cc0d6bade8d369f57040990756f Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit b3f028fc8abdf72c6ed1103e60e89dd60538f126) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 10 Feb 2017 07:46:50 +0000 (23:46 -0800)]
i40e: Clean up dead code
The function i40e_client_prepare() can never return an error. So make it
void and quit checking its return value.
Change-ID: I9ff311e2324dde329eb68648efb2c94aaff856db Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 3bb83baf9ac9c73f4da051cae17042f264832e61) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 29 Nov 2016 00:06:11 +0000 (16:06 -0800)]
i40e/i40evf : Changed version from 1.6.25 to 1.6.27
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>
Orabug: 26132523
(cherry picked from commit cfffef76e7fa5b9ac3ec8298336d0265bc86af3c) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 10 Feb 2017 07:44:27 +0000 (23:44 -0800)]
i40e: update comment explaining where FDIR buffers are freed
The original comment implies that the only location where the raw_packet
buffer will be freed is in i40e_clean_tx_ring() which is incorrect. In
fact this isn't even the normal case. Update the comment explaining
where the memory is freed.
Change-ID: Ie0defc35ed1c3af183f81fdc60b6d783707a5595 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit a158aeaf5bb5b014240b360693751476aca7440b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:43:30 +0000 (23:43 -0800)]
i40e/i40evf: eliminate i40e_pull_tail()
Reorganize the i40e_pull_tail() logic, doing it in i40e_add_rx_frag()
where it's cheaper. The igb driver does this the same way.
Also renames i40e_page_is_reserved() to reflect what it actually
tests.
Change-ID: Icd9cc507aae1fcdc02308b3a09034111b4c24071 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9b37c937313bf6769d0b018ca35180b379d40862) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:40:25 +0000 (23:40 -0800)]
i40e/i40evf: Moves skb from i40e_rx_buffer to i40e_ring
This patch reduces the size of struct i40e_rx_buffer by one pointer,
and makes the i40e driver a little more consistent with the igb driver
in terms of packets that span buffers.
We do this by moving the skb field from struct i40e_rx_buffer to
struct i40e_ring. We pass the skb we already have (or NULL if we
don't) to i40e_fetch_rx_buffer(), which skips the skb allocation if we
already have one for this packet.
Change-ID: I4ad48a531844494ba0c5d8e1a62209a057f661b0 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit e72e56597ba15ce70f4fc1eb2ceeaa8da0d4ab5e) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Scott Peterson [Fri, 10 Feb 2017 07:37:28 +0000 (23:37 -0800)]
i40e/i40evf: Limit DMA sync of RX buffers to actual packet size
On packet RX, we perform a DMA sync for CPU before passing the
packet up. Here we limit that sync to the actual length of the
incoming packet, rather than always syncing the entire buffer.
Change-ID: I626aaf6c37275a8ce9e81efcaa773f327b331487 Signed-off-by: Scott Peterson <scott.d.peterson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7987dcd7b95111a5acbf5abdbf155eedacd3546b) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Mitch Williams [Fri, 10 Feb 2017 07:35:18 +0000 (23:35 -0800)]
i40evf: track outstanding client request
The iWarp client cannot continue until this operation has been completed
by the PF driver. Sleep (with timeout) until the reply from the PF
driver has been received.
Change-ID: I5dc41b857bba32d0218b7ce167b5da122dadf349 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 e5f77f4a2ff2d6ce2d973ebc62084d92f203c9f6) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
projects / users / jedix / linux-maple.git / log