From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp1.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4905B201A59 for ; Thu, 12 May 2011 09:34:11 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0027.austin.hp.com (Postfix) with ESMTP id D8E543809B; Thu, 12 May 2011 16:41:59 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 6543C3405E; Thu, 12 May 2011 16:41:59 +0000 (UTC) From: Rick Jones To: Fred Baker 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> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 May 2011 09:41:58 -0700 Message-ID: <1305218518.8149.499.camel@tardy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: Stephen Hemminger , bloat@lists.bufferbloat.net Subject: Re: [Bloat] Burst Loss X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: rick.jones2@hp.com List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 16:34:11 -0000 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