Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 23 7月, 2015 1 次提交
    • M
      i40evf: handle big resets · e6d038de
      由 Mitch Williams 提交于 
      The most common type of reset that the VF will encounter is a PF reset
that cascades down into a VF reset for each VF. In this case, the VF
will always be assigned the same VSI and recovery is fairly simple.

However, in the case of 'bigger' resets, such as a Core or EMP reset,
when the device is reinitialized, it's probable that the VF will NOT get
the same VSI. When this happens, the VF will not be able to recover, as
it will continue to request resources for its original VSI.

Add an extra state to the admin queue state machine so that the driver
can re-request its configuration information at runtime. During reset
recovery, set this bit in the aq_required field, and fetch the (possibly
new) configuration information before attempting to bring the driver
back up. Since the driver doesn't know what kind of reset it has
encountered, this step is done even for a PF reset, but it doesn't hurt
anything - it just gets the same VSI back.

Change-ID: I915d59ffb40375215117362f4ac7a37811aba748
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e6d038de
  3. 15 7月, 2015 4 次提交
  5. 26 6月, 2015 2 次提交
  7. 15 4月, 2015 2 次提交
  9. 03 4月, 2015 2 次提交
  11. 27 3月, 2015 2 次提交
  13. 10 3月, 2015 1 次提交
  15. 09 3月, 2015 3 次提交
  17. 07 3月, 2015 1 次提交
  19. 06 3月, 2015 1 次提交
  21. 03 3月, 2015 1 次提交
  23. 25 2月, 2015 2 次提交
  25. 24 2月, 2015 5 次提交
    • M
      i40evf: don't wait forever · 54e16f64
      由 Mitch Williams 提交于 
      Under rare circumstances, after a reset, set_rx_mode might get called
while the watchdog is running, which will cause a deadlock on the
critical section lock. To correct this, add a counter and give up trying
to get the lock after fifty tries. Log a message if this happens but
don't take any other action. Because this happens after a reset, all of
the Rx filters are still in place and the device won't lose
connectivity.

We can also get stuck during shutdown, if the PF has stopped communicating
with us, or if a reset is occurring. If we can't get the lock after a reasonable
amount of time, just error out. Something else bad is happening anyway, so
adding this filter is the least of our concern right now.

Change-ID: I159731e2a82a06b389ee31b34ce336548e05baa0
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      54e16f64
    • M
      i40evf: refactor reset · ac833bbf
      由 Mitch Williams 提交于 
      A recent change to the shutdown flow messed up the reset flow. Since
i40evf_down now holds the critical section lock, we cannot call it from
the reset handler, which also holds the lock. To do so causes a deadlock
accompanied by wailing and gnashing of teeth. This is easily triggered
by running an ethtool self-test on the PF device.

Instead, we move the relevant portions of i40evf_down into the reset
handler and bend them to our will. Additionally, we can optimize the
reinit path by not deleting the MAC and VLAN filters and then adding
them back again. Instead, we just set the 'add' flag and let the
watchdog resynchronize the filter list with the PF driver. We also
reword a few messages to make them more consistent with the rest of the
driver.

Change-ID: I03dd92ae736f7719fca3564b12a2cf9b98c6cb18
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ac833bbf
    • M
      i40evf: disable NAPI polling sooner · 748c434b
      由 Mitch Williams 提交于 
      When closing the interface, disable NAPI polling before any other
activities. This fixes an occasional panic during close caused by the
driver trying to delete and clean rings at the same time.

Change-ID: Ib4d427b13d310258ea85b248d535da70ecf0c1e9
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      748c434b
    • S
      i40e/i40evf: Bump Driver Versions · c952f6c7
      由 Sravanthi Tangeda 提交于 
      Bump i40e to 1.2.8 and i40evf to 1.2.2

Change-ID: I64f47c3367ea8ff2a53068e895d7a1f60726c871
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c952f6c7
    • M
      i40e/i40evf: Refactor the receive routines · a132af24
      由 Mitch Williams 提交于 
      Split the receive hot path code into two, one for packet split and one
for single buffer. This improves receive performance since we only need
to check if the ring is in packet split mode once per NAPI poll time,
not several times per packet. The single buffer code is further improved
by the removal of a bunch of code and several variables that are not
needed. On a receive-oriented test this can improve single-threaded
throughput.

Also refactor the packet split receive path to use a fixed buffer for
headers, like ixgbe does. This vastly reduces the number of DMA mappings
and unmappings we need to do, allowing for much better performance in
the presence of an IOMMU.

Lastly, correct packet split descriptor types now that we are actually
using them.

Change-ID: I3a194a93af3d2c31e77ff17644ac7376da6f3e4b
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a132af24
  27. 09 2月, 2015 3 次提交
  29. 16 1月, 2015 2 次提交
  31. 14 1月, 2015 7 次提交
  33. 06 12月, 2014 1 次提交