Thread (45 messages) flat view 45 messages, 11 authors, 2006-08-22

Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2006-08-19 04:32:13
Also in: linuxppc-dev, lkml

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
quoted
quoted
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 ? :)
quoted
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.
quoted
I'm somewhat disoriened from this conversation. Its presumably
clear that low-watermark mechanisms are superior to NAPI. 
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help