From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "sj-iport-6.cisco.com", Issuer "Cisco SSCA" (not verified)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BB146201A59 for ; Thu, 12 May 2011 09:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=991; q=dns/txt; s=iport; t=1305217884; x=1306427484; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=+fAsOdoAKQgDRch2QVA7qUCesgZBCT1cA1+k3UVFvp8=; b=Tmgfn9bo7ufPxnqnUGSf7mUu2hjNI+hQPhf+MjhRIMtGxDu0acpqgfrL dPEJyca2QXaY2WNkETaZKMDqfN+KO4ft+ftXZ45QUsDPSjpaJKhZR2kga LBW+AdUmKlmVzSU9fKWMFyrqUJ21bNTBghsRq1OPnaSIFFFtTHXfrkSZV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEHALcKzE2rRDoH/2dsb2JhbACYAI14d4hwoEKeJYYVBIZJiTKEKIph X-IronPort-AV: E=Sophos;i="4.64,359,1301875200"; d="scan'208";a="696388864" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 12 May 2011 16:31:22 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4CGVHQt030346; Thu, 12 May 2011 16:31:22 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 12 May 2011 09:31:22 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 12 May 2011 09:31:22 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <1304964368.8149.202.camel@tardy> Date: Thu, 12 May 2011 09:31:03 -0700 Message-Id: <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> To: rick.jones2@hp.com X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 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:23:34 -0000 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.=