Netdev List
 help / color / mirror / Atom feed
From: linas@austin.ibm.com (Linas Vepstas)
To: akepner@sgi.com, Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	James K Lewis <jklewis@us.ibm.com>, Arnd Bergmann <arnd@arndb.de>,
	"cbe-oss-dev@ozlabs.org" <cbe-oss-dev@ozlabs.org>,
	cbe-oss-dev-bounces+jklewis=us.ibm.com@ozlabs.org,
	Christoph Hellwig <hch@lst.de>,
	netdev@vger.kernel.org
Subject: Re: NAPI wait before enabling irq's [was Re: [Cbe-oss-dev] Spider DMA wrongness]
Date: Thu, 14 Dec 2006 16:49:52 -0600	[thread overview]
Message-ID: <20061214224952.GB4329@austin.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0612141244160.30447@localhost.localdomain>

On Thu, Dec 14, 2006 at 12:51:14PM -0800, akepner@sgi.com wrote:
> On Thu, 14 Dec 2006, Linas Vepstas wrote:
> 
> >On Wed, Nov 08, 2006 at 07:38:12AM +1100, Benjamin Herrenschmidt wrote:
> >>
> >>What about Linas patches to do interrupt mitigation with NAPI polling ?
> >>That didn't end up working ?
> >
> >It seems to be "working as designed", which is different than "working
> >as naively expected".
> >
> >For large packets:
> >-- a packet comes in
> >-- rx interrupt generated
> >-- rx interrupts turned off
> >-- tcp poll function runs, receives packet
> >-- completes all work before next packet has arrived,
> >  so interupts are turned back on.
> >-- go to start
> >
> >This results in a high number of interrupts, and a high cpu usage.
> >We were able to prove that napi works by stalling in the poll function
> >just long enough to allow the next packet to arrive.  In this case,
> >napi works great, and number of irqs is vastly reduced.
> >....
> 
> This sounds awfully familiar. We went through the same
> with the tg3 driver on Altix. In that case we succeeded
> getting interrupt coalescence added to the driver, which
> ended up working pretty well for us. See the thread
> beginning with:
> 
> http://oss.sgi.com/archives/netdev/2005-05/msg00497.html
> 
> if you're interested.

I'm interested. The tg3 seems to have "hardware coalescing",
which, from what I can tell, is a way of delaying an RX
interrupt for some number of microseconds?  I assume there's 
nothing more to it than that?

The spider has some suggestively named registers and functions,
hinting that it can similarly delay an RX interupt, but the 
docs are opaque and mysteriously worded, so I cannot really tell.

Perhaps Ishizaki Kou can clue us in? 

> As for the "stalling NAPI" idea, Jamal did a bit of work
> with that idea and wrote it up in:
> 
> www.kernel.org/pub/linux/kernel/people/hadi/docs/UKUUG2005.pdf

Reading now ... 

--linas

      reply	other threads:[~2006-12-14 22:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OFBF8BBD4B.0E5AEA34-ON8725721F.005D5313-8625721F.005EAC5D@us.ibm.com>
     [not found] ` <1162931892.28571.497.camel@localhost.localdomain>
2006-12-14 20:54   ` NAPI wait before enabling irq's [was Re: [Cbe-oss-dev] Spider DMA wrongness] Linas Vepstas
2006-12-14 20:51     ` akepner
2006-12-14 22:49       ` Linas Vepstas [this message]

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=20061214224952.GB4329@austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=akepner@sgi.com \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=cbe-oss-dev-bounces+jklewis=us.ibm.com@ozlabs.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=hch@lst.de \
    --cc=jklewis@us.ibm.com \
    --cc=kou.ishizaki@toshiba.co.jp \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox