From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by huchra.bufferbloat.net (Postfix) with SMTP id 395A7201AD0 for ; Thu, 12 May 2011 21:52:37 -0700 (PDT) Received: (qmail 17019 invoked by uid 0); 13 May 2011 05:00:40 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy3.bluehost.com with SMTP; 13 May 2011 05:00:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=avanw.com; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From:To:Content-Type:X-Identified-User; b=IGXRhr7bR6VkcCDmD1Q+6G4F6Xe5JEgEle92ORNtytjq198SaIDQXylrEw+wJw3YlZr8T5cyRE3EYUahJMgC9YKcuKe8lZZL6/Vi5bN81FrvPDu7NXrtZr1k0LdtUmRj; Received: from mail-fx0-f43.google.com ([209.85.161.43]) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1QKkUS-0003hT-82 for bloat@lists.bufferbloat.net; Thu, 12 May 2011 23:00:40 -0600 Received: by fxm3 with SMTP id 3so2508600fxm.16 for ; Thu, 12 May 2011 22:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.101.72 with SMTP id b8mr1211671fao.15.1305262838530; Thu, 12 May 2011 22:00:38 -0700 (PDT) Received: by 10.223.117.209 with HTTP; Thu, 12 May 2011 22:00:38 -0700 (PDT) In-Reply-To: <4DD9A464-8845-49AA-ADC4-A0D36D91AAEC@cisco.com> References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org> <20110505091046.3c73e067@nehalam> <6E25D2CF-D0F0-4C41-BABC-4AB0C00862A6@pnsol.com> <35D8AC71C7BF46E29CC3118AACD97FA6@srichardlxp2> <1304964368.8149.202.camel@tardy> <4DD9A464-8845-49AA-ADC4-A0D36D91AAEC@cisco.com> Date: Thu, 12 May 2011 23:00:38 -0600 Message-ID: From: Kevin Gross To: bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=00151743f918d4432c04a3212f57 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.161.43 authed with kevin.gross@avanw.com} Subject: Re: [Bloat] Burst Loss X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 04:52:38 -0000 --00151743f918d4432c04a3212f57 Content-Type: text/plain; charset=ISO-8859-1 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. Kevin Gross On Thu, May 12, 2011 at 10:31 AM, 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. 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. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --00151743f918d4432c04a3212f57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 g= round on this. For a short time, servers with gigabit NICs suffered but sma= rter NICs were developed (TSO, LRO, other TLAs) and OSs upgraded to support= them and I believe it is no longer a significant issue.

Kevin Gross

On Thu, May 12= , 2011 at 10:31 AM, Fred Baker <fred@cisco.com> 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 IEE= E)
> refusing to standardize an increase in frame sizes. =A0Put another way= ,
> they are a "poor man's jumbo frames."

I'll agree, but only half; once the packets are transferred on the loca= l 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. Th= e 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 by= te frames, and as a result the receiver experiences 1/5 or 1/6 of the inter= rupts. Given that it has to save state, activate the kernel thread, and at = least enqueue and perhaps acknowledge the received message, reducing interr= upt load on the receiver makes it far more effective. This has the greatest= effect on multi-gigabit file transfers.
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat

--00151743f918d4432c04a3212f57--