From: Stephen Hemminger <shemminger@linux-foundation.org>
To: James Chapman <jchapman@katalix.com>
Cc: hadi@cyberus.ca, Bill Fink <billfink@mindspring.com>,
netdev@vger.kernel.org, davem@davemloft.net, jeff@garzik.org,
mandeep.baines@gmail.com, ossthema@de.ibm.com
Subject: Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates
Date: Wed, 12 Sep 2007 16:02:39 +0200 [thread overview]
Message-ID: <20070912160239.70a580e8@oldman> (raw)
In-Reply-To: <46E7EE89.9060006@katalix.com>
On Wed, 12 Sep 2007 14:50:01 +0100
James Chapman <jchapman@katalix.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.
next prev parent reply other threads:[~2007-09-12 14:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-06 14:16 RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates James Chapman
2007-09-06 14:37 ` Stephen Hemminger
2007-09-06 15:30 ` James Chapman
2007-09-06 15:37 ` Stephen Hemminger
2007-09-06 16:07 ` James Chapman
2007-09-06 23:06 ` jamal
2007-09-07 9:31 ` James Chapman
2007-09-07 13:22 ` jamal
2007-09-10 9:20 ` James Chapman
2007-09-10 12:27 ` jamal
2007-09-12 7:04 ` Bill Fink
2007-09-12 12:12 ` jamal
2007-09-12 13:50 ` James Chapman
2007-09-12 14:02 ` Stephen Hemminger [this message]
2007-09-12 16:26 ` James Chapman
2007-09-12 16:47 ` Mandeep Baines
2007-09-13 6:57 ` David Miller
2007-09-14 13:14 ` jamal
2007-09-07 21:20 ` Jason Lunz
2007-09-10 9:25 ` James Chapman
2007-09-07 3:55 ` Mandeep Singh Baines
2007-09-07 9:38 ` James Chapman
2007-09-08 16:42 ` Mandeep Singh Baines
2007-09-10 9:33 ` James Chapman
2007-09-10 12:12 ` jamal
2007-09-08 16:32 ` Andi Kleen
2007-09-10 9:25 ` James Chapman
2007-09-12 15:12 ` David Miller
2007-09-12 16:39 ` James Chapman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070912160239.70a580e8@oldman \
--to=shemminger@linux-foundation.org \
--cc=billfink@mindspring.com \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=jchapman@katalix.com \
--cc=jeff@garzik.org \
--cc=mandeep.baines@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=ossthema@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.