diff options
author | Jesse Brandeburg <jesse.brandeburg@intel.com> | 2018-11-09 01:55:32 +0300 |
---|---|---|
committer | Jeff Kirsher <jeffrey.t.kirsher@intel.com> | 2018-11-21 21:35:23 +0300 |
commit | 0bcd952feec7042d9a5383b639c8edc943402add (patch) | |
tree | 4965b0ebd92e9d982468d72fa183ba4346a93404 /lib/test_bpf.c | |
parent | 09e58b2d538cfd4fa3f48bc4fc78ba1c1b28b05a (diff) | |
download | linux-0bcd952feec7042d9a5383b639c8edc943402add.tar.xz |
ethernet/intel: consolidate NAPI and NAPI exit
While reviewing code, I noticed that Eric Dumazet recommends that
drivers check the return code of napi_complete_done, and use that
to decide to enable interrupts or not when exiting poll. One of
the Intel drivers was already fixed (ixgbe).
Upon looking at the Intel drivers as a whole, we are handling our
polling and NAPI exit in a few different ways based on whether we
have multiqueue and whether we have Tx cleanup included. Several
drivers had the bug of exiting NAPI with return 0, which appears
to mess up the accounting in the stack.
Consolidate all the NAPI routines to do best known way of exiting
and to just mostly look like each other.
1) check return code of napi_complete_done to control interrupt enable
2) return the actual amount of work done.
3) return budget immediately if need NAPI poll again
Tested the changes on e1000e with a high interrupt rate set, and
it shows about an 8% reduction in the CPU utilization when busy
polling because we aren't re-enabling interrupts when we're about
to be polled.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Diffstat (limited to 'lib/test_bpf.c')
0 files changed, 0 insertions, 0 deletions