lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20070912160239.70a580e8@oldman> Date: Wed, 12 Sep 2007 16:02:39 +0200 From: Stephen Hemminger <shemminger@...ux-foundation.org> To: James Chapman <jchapman@...alix.com> Cc: hadi@...erus.ca, Bill Fink <billfink@...dspring.com>, netdev@...r.kernel.org, davem@...emloft.net, jeff@...zik.org, mandeep.baines@...il.com, ossthema@...ibm.com Subject: Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates On Wed, 12 Sep 2007 14:50:01 +0100 James Chapman <jchapman@...alix.com> wrote: > jamal wrote: > > On Wed, 2007-12-09 at 03:04 -0400, Bill Fink wrote: > >> On Fri, 07 Sep 2007, jamal wrote: > > > >>> I am going to be the devil's advocate[1]: > >> So let me be the angel's advocate. :-) > > > > I think this would make you God's advocate ;-> > > (http://en.wikipedia.org/wiki/God%27s_advocate) > > > >> I view his results much more favorably. > > > > The challenge is, under _low traffic_: bad bad CPU use. > > Thats what is at stake, correct? > > By low traffic, I assume you mean a rate at which the NAPI driver > doesn't stay in polled mode. The problem is that that rate is getting > higher all the time, as interface and CPU speeds increase. This results > in too many interrupts and NAPI thrashing in/out of polled mode very > quickly. But if you compare this to non-NAPI driver the same softirq overhead happens. The problem is that for many older devices disabling IRQ's require an expensive non-cached PCI access. Smarter, newer devices all use MSI which is pure edge triggered and with proper register usage, NAPI should be no worse than non-NAPI. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists