On Wed, 19 May 2010, Thomas Gleixner wrote: > > I'm still not clear on why the ultimate solution wasn't to have XICS report > > edge triggered as edge triggered. Probably some complexity of the entire > > power > > stack that I am ignorant of. > > > > > Apart from the issue of loosing interrupts there is also the fact that > > > masking on the XICS requires an RTAS call which takes a global lock. > > Right, I'd love to avoid that but with real level interrupts we'd run > into an interrupt storm. Though another solution would be to issue the > EOI after the threaded handler finished, that'd work as well, but > needs testing.
Thought more about that. The case at hand (ehea) is nasty: The driver does _NOT_ disable the rx interrupt in the card in the rx interrupt handler - for whatever reason. So even in mainline you get repeated rx interrupts when packets arrive while napi is processing the poll, which is suboptimal at least. In fact it is counterproductive as the whole purpose of NAPI is to _NOT_ get interrupts for consecutive incoming packets while the poll is active. Most of the other network drivers do: rx_irq() disable rx interrupts on card napi_schedule() Now when the napi poll is done (no more packets available) then the driver reenables the rx interrupt on the card. Thanks, tglx _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev