> As a host you have half the interrupts, so it is less critical. The problem
As a host you have the same number of interrupts because you are still acking
frames. At best with TCP you have 3/4 of them, and you have a higher per
packet processing load
> processing the data as it arrives if you disable the per-packet interrupt,
> so you are discarding data that doesn't need to be to save cpu cycles that
> very well may not need to be saved.
If you don't start dropping interrupt events you never get to process the
data. Keeping up with the interrupts eventually takes you to the point of
100% interrupt keep up, 0% work done.
> Real overloads take care of themselves in the form of ring overruns...you
> can tune the size of the rings in most cases as well....causing overloads
> by not processing the data properly is not a "win"
Demonstrably not the case. You can stall a PC with a hardware packet
generator just on IRQ load at 100Mbit, let alone Gbit
> >is basically free given enough buffer memory and adds almost no latency if
> >any at all.
>
> its "free" if you can keep your transmit ring full without them. Perhaps on
> ethernet mediums where you have forced gaps this "philosophy" is more
The transmit ring doesnt need to be full, it needs never to be empty. That
gives you half a ring of buffering trivially. This is what most Linux
network drivers do at high speeds. Providing you cant hit the IRQ timing needed
never to empty the ring, then the full duplex ethernet sends flat out with
no gaps and you take 1/16 or 1/32 of the interrupt rate.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.rutgers.edu
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:27 EST