[Intel-wired-lan] [net-next v2 2/2] ethernet/intel: consolidate napi and napi exit

Keller, Jacob E jacob.e.keller at intel.com
Fri Nov 9 23:29:29 UTC 2018


> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On Behalf Of Jeff
> Kirsher
> Sent: Thursday, November 08, 2018 2:56 PM
> To: intel-wired-lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [net-next v2 2/2] ethernet/intel: consolidate napi and napi
> exit
> 
> From: Jesse Brandeburg <jesse.brandeburg at intel.com>
> 
> 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 at intel.com>

The fm10k changes look good to me. Thanks Jesse! For those:

Reviewed-by: Jacob Keller <jacob.e.keller at intel.com>


More information about the Intel-wired-lan mailing list