[Bloat] Burst Loss
Rick Jones
rick.jones2 at hp.com
Thu May 12 12:41:58 EDT 2011
On Thu, 2011-05-12 at 09:31 -0700, Fred Baker wrote:
> On May 9, 2011, at 11:06 AM, Rick Jones wrote:
>
> > GSO/TSO can be thought of as a symptom of standards bodies (eg the IEEE)
> > refusing to standardize an increase in frame sizes. Put another way,
> > they are a "poor man's jumbo frames."
>
> I'll agree, but only half; once the packets are transferred on the
> local wire, any jumbo-ness is lost.
That is why I called them "poor man's" - he can't have everything :)
> GSO/TSO mostly squeezes interframe gaps out of the wire and perhaps
> limits the amount of work the driver has to do. The real value of an
> end to end (IP) jumbo frame is that the receiving system experiences
> less interrupt load - a 9K frame replaces half a dozen 1500 byte
> frames, and as a result the receiver experiences 1/5 or 1/6 of the
> interrupts. Given that it has to save state, activate the kernel
> thread, and at least enqueue and perhaps acknowledge the received
> message, reducing interrupt load on the receiver makes it far more
> effective. This has the greatest effect on multi-gigabit file
> transfers.
Perhaps I'm trying to argue about the number of angels which can dance
on the head of a pin, but isn't mitigating interrupt rates something
that NICs and their drivers (and NAPI in the context of Linux) been
doing for years?
Or are you using "interrupt" to refer to the entire trip up the protocol
stack and not just "interupts?"
And then there is GRO/LRO.
Of course as all the world is not bulk flows, one still has to write a
nice, tight, stack and driver :)
rick jones
More information about the Bloat
mailing list