From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: arnd@arndb.de, netdev@vger.kernel.org, jklewis@us.ibm.com,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Jens.Osterkamp@de.ibm.com
Subject: Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
Date: Sat, 19 Aug 2006 14:31:20 +1000 [thread overview]
Message-ID: <1155961881.5803.65.camel@localhost.localdomain> (raw)
In-Reply-To: <20060818.155116.112621100.davem@davemloft.net>
On Fri, 2006-08-18 at 15:51 -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Fri, 18 Aug 2006 17:46:18 -0500
>
> > > We're not saying to use the RX interrupt as the trigger for
> > > RX and TX work. Rather, either of RX or TX interrupt will
> > > schedule the NAPI poll.
> >
> > And, for a lark, this is exactly what I did. Just to see.
> > Because there are so few ack packets, there are very few
> > RX interrupts -- not enough to get NAPI to actually keep
> > the device busy.
>
> You're misreading me. TX interrupts are intended to be "enabled" and
> trigger NAPI polls. TX IRQ enabled, enabled :-)
Maybe be because you actually typed "disabled" in your previous
message ? :)
>> The idea is to use NAPI polling with TX interrupts disabled.
> If you want to eliminate them if the kernel keeps hopping into
> the ->hard_start_xmit() via hw interrupt mitigation or whatever,
> that's fine. But if you do need to do TX interrupt processing,
> do it in NAPI ->poll().
Well, we do need to harvest descriptors of course, though I suppose that
can be done in hard_xmit as well. I'm not sure if there is any real
benefit in batching those.
> > I'm somewhat disoriened from this conversation. Its presumably
> > clear that low-watermark mechanisms are superior to NAPI.
> > >From what I gather, NAPI was invented to deal with cheap
> > or low-function hardware; it adds nothing to this particular
> > situation. Why are we talking about this?
>
> NAPI is meant to give fairness to all devices receiving packets
> in the system, particularly in times of high load or overload.
>
> And equally importantly, it allows you to run the majority of your
> interrupt handler in software IRQ context.
That is the most important point imho for the specific case of spidernet
on cell.
> This allows not only your
> locking to be simpler, but it also allows things like oprofile to
> monitor almost your entire IRQ processing path even with just timer
> interrupt based oprofile profiling.
>
> I see you moving TX reclaim into tasklets and stuff. I've vehemently
> against that because you wouldn't need it in order to move TX
> processing into software interrupts if you did it all in NAPI
> ->poll().
Ben.
next prev parent reply other threads:[~2006-08-19 4:32 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-11 17:03 [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes Linas Vepstas
2006-08-11 17:06 ` [PATCH 1/4]: powerpc/cell spidernet burst alignment patch Linas Vepstas
2006-08-11 17:08 ` [PATCH 2/4]: powerpc/cell spidernet low watermark patch Linas Vepstas
2006-08-16 23:43 ` Benjamin Herrenschmidt
2006-08-18 19:23 ` Linas Vepstas
2006-08-18 21:25 ` David Miller
2006-08-18 22:46 ` Linas Vepstas
2006-08-18 22:51 ` David Miller
2006-08-18 23:29 ` Linas Vepstas
2006-08-18 23:45 ` Linas Vepstas
2006-08-19 4:33 ` Benjamin Herrenschmidt
2006-08-22 0:13 ` Linas Vepstas
2006-08-22 0:30 ` David Miller
2006-08-19 4:31 ` Benjamin Herrenschmidt [this message]
2006-08-11 17:09 ` [PATCH 3/4]: powerpc/cell spidernet stop error printing patch Linas Vepstas
2006-08-11 17:11 ` [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info Linas Vepstas
2006-08-11 18:00 ` Olof Johansson
2006-08-11 18:50 ` James K Lewis
2006-08-11 19:46 ` Linas Vepstas
2006-08-15 19:05 ` Olof Johansson
2006-08-16 0:29 ` Michael Ellerman
2006-08-11 17:42 ` [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes jschopp
2006-08-11 17:44 ` Sam Ravnborg
2006-08-11 19:31 ` Linas Vepstas
2006-08-11 20:27 ` Arnd Bergmann
2006-08-16 16:18 ` [PATCH 1/2]: powerpc/cell spidernet bottom half Linas Vepstas
2006-08-16 16:30 ` Jeff Garzik
2006-08-16 20:30 ` Linas Vepstas
2006-08-16 20:34 ` Jeff Garzik
2006-08-16 20:46 ` David Miller
2006-08-16 21:24 ` Arnd Bergmann
2006-08-16 21:32 ` David Miller
2006-08-16 22:16 ` Arnd Bergmann
2006-08-16 22:29 ` David Miller
2006-08-16 22:47 ` Arnd Bergmann
2006-08-16 23:30 ` Linas Vepstas
2006-08-16 23:32 ` David Miller
2006-08-17 0:23 ` Linas Vepstas
2006-08-16 23:24 ` Linas Vepstas
2006-08-16 22:55 ` Linas Vepstas
2006-08-16 23:03 ` Arnd Bergmann
2006-08-16 23:47 ` Linas Vepstas
2006-08-16 23:08 ` Rick Jones
2006-08-16 21:58 ` Linas Vepstas
2006-08-16 16:23 ` [PATCH 2/2]: powerpc/cell spidernet refine locking Linas Vepstas
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=1155961881.5803.65.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=Jens.Osterkamp@de.ibm.com \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=jklewis@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--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;
as well as URLs for NNTP newsgroup(s).