[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