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 -0500quoted
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 cheapor 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.