Andrew Morton writes:
> > > Behaviour under 2.2.19 kernel:
> > >
> > > Time: 1 minute 8 seconds
> > > RX packets (aprox): 3 million overruns: 81000
> > >
> > > Interrupts as mesured by vmstat 1: from 35000 to 40000 (38500 average)
> > >
> > Big difference from 6500 ;-> This is over 6 times more.
I did't follow comparision.
> And the userspace throughput was an order of magnitude better. Fascinating.
>
> One could envisage one scenario where a less efficient interrupt
> routine results in more throughput: suppose the ISR takes 9 usecs
> and frames are arriving at 10 usec intervals. That's one interrupt per
> frame and userspace starvation. If you slow the ISR down a bit then
> it will end up handling two packets per interrupt and, assuming that
> the entry and exit is the majority of the cost, you'll end up actually
> yielding more time for userspace processing. But the most this can
> possibly account for is a factor of two, not a factor of ten.
Yes kind of mitigation but hard to tune. :-)
And with the NAPI you can get more RX-irqs compared to an Interrupt
Mitigation scheme. This at packet rates before the switch consecutive
poll occurs. So some people may be very suprised why RX interrupts did
not go away with "polling". The worst case behaviour is very good.
But is up to driver choose done/not_done strategy. Also it possible to
have RX hardware IM on with NAPI. But it would be nice if reduce
complexity and have a very clean interface.
My experiences with Interrupt Mitigation isn't too good especially
with GIGE. At start I was really blended by amazing few interrupts
and pretty good performance. After some months of tuning to improve
performance at all packet sizes. I more or less give this up its too
fragile at least for me. I prefer more robust and simpler scheme
even if it would cost some performance.
> Weird stuff. Martin, do you have a URL for udpspam?
As an alternative: The packet generator I use is now in Alexeys iputils
package. pg3.c.
Cheers.
--ro
|