Messages in this thread | | | Subject | Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch. | From | Benjamin Herrenschmidt <> | Date | Sat, 19 Aug 2006 14:31:20 +1000 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |