On Thu, 02 Feb 2006 08:35:28 -0700 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> "Christopher Friesen" <[EMAIL PROTECTED]> writes: > > > Eric W. Biederman wrote: > >> Jeff Garzik <[EMAIL PROTECTED]> writes: > > > >>> This was discussed on the netdev list, and the conclusion was that > >>> you want both NAPI and hw mitigation. This was implemented in a > >>> few drivers, at least. > > > >> How does that deal with the latency that hw mitigation introduces. When you > >> have a workload that bottle-necked waiting for that next > >> packet and hw mitigation is turned on you can see some horrible > >> unjustified slow downs. > > > > Presumably at low traffic you would disable hardware mitigation to get the > > best > > possible latency. As traffic ramps up you tune the hardware mitigation > > appropriately. At high traffic loads, you end up with full hardware > > mitigation, > > but you have enough packets coming in that the latency is minimal. > > The evil but real work load is when you have a high volume of dependent > traffic. > RPC calls or MPI collectives are cases where you are likely to see this. > > Or even in TCP there is an element that once you hit your window limit you > won't > send more traffic until you get your ack. But if you don't get your ack > because the interrupt is mitigated. > > NAPI handles this beautifully. It disables the interrupts until it knows it > needs to process more packets. Then when it is just waiting around for > packets from that card it enables interrupts on that card. Also, NAPI handles the case where receiver is getting DoS or overrrun with packets, and you want the hardware to send flow control. Without NAPI it is easy to get stuck only processing packets and nothing else. I hope the VJ channels code has receive flow control. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
