One of the principal reasons jumbo frames have not been standardized is due to latency concerns. I assume this group can appreciate the IEEE holding ground on this. For a short time, servers with gigabit NICs suffered but smarter NICs were developed (TSO, LRO, other TLAs) and OSs upgraded to support them and I believe it is no longer a significant issue.<div>
<br></div><div>Kevin Gross<br><br><div class="gmail_quote">On Thu, May 12, 2011 at 10:31 AM, Fred Baker <span dir="ltr"><<a href="mailto:fred@cisco.com">fred@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On May 9, 2011, at 11:06 AM, Rick Jones wrote:<br>
<br>
> GSO/TSO can be thought of as a symptom of standards bodies (eg the IEEE)<br>
> refusing to standardize an increase in frame sizes.  Put another way,<br>
> they are a "poor man's jumbo frames."<br>
<br>
I'll agree, but only half; once the packets are transferred on the local wire, any jumbo-ness is lost. 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.<br>

_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</blockquote></div><br></div>