David Miller wrote:
From: James Chapman <[email protected]>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
