Re: RFC: issues concerning the next NAPI interface

James Chapman
2007-08-26T19:41:36Z

David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Fri, 24 Aug 2007 18:16:45 +0100
>
>> Does hardware interrupt mitigation really interact well with NAPI?
>
> It interacts quite excellently.

If NAPI disables interrupts and keeps them disabled while there are more
packets arriving or more transmits being completed, why do hardware
interrupt mitigation / coalescing features of the network silicon help?

> There was a long saga about this with tg3 and huge SGI numa
> systems with large costs for interrupt processing, and the
> fix was to do a minimal amount of interrupt mitigation and
> this basically cleared up all the problems.
>
> Someone should reference that thread _now_ before this discussion goes
> too far and we repeat a lot of information and people like myself have
> to stay up all night correcting the misinformation and
> misunderstandings that are basically guarenteed for this topic :)

I hope I'm not spreading misinformation. :) The original poster was
observing NAPI going in/out of polled mode because the CPU is fast
enough to process all work per poll. I've seen the same and I'm
suggesting that the NAPI driver keeps itself in polled mode for N polls
or M jiffies after it sees workdone=0. This has always worked for me in
packet forwarding scenarios to maximize packets/sec and minimize
latency. I'm considering putting a patch together to add this as another
tuning knob, hence I'm keen to understand what I'm missing. :)

--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development