From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-ewr.dyndns.com (mxout-068-ewr.mailhop.org [216.146.33.68]) by lists.bufferbloat.net (Postfix) with ESMTP id C2F142E0117 for ; Fri, 25 Feb 2011 03:22:14 -0800 (PST) Received: from scan-02-ewr.mailhop.org (scan-02-ewr.local [10.0.141.224]) by mail-04-ewr.dyndns.com (Postfix) with ESMTP id A538E7E482C for ; Fri, 25 Feb 2011 11:21:58 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 87.72.215.196 Received: from lanfw001a.cxnet.dk (lanfw001a.cxnet.dk [87.72.215.196]) by mail-04-ewr.dyndns.com (Postfix) with ESMTP id C73FC7E47A2; Fri, 25 Feb 2011 11:21:55 +0000 (UTC) Received: from [87.72.44.6] (lanvpn001a.cxnet.dk [87.72.215.222]) by lanfw001a.cxnet.dk (Postfix) with ESMTP id 676D31635BE; Fri, 25 Feb 2011 12:21:53 +0100 (CET) Subject: GSO (was: Please enter issues into the issue tracker - Issue system organisation needed) From: Jesper Dangaard Brouer To: Eric Dumazet In-Reply-To: <1298575769.2659.10.camel@edumazet-laptop> References: <4D6668F4.5010705@freedesktop.org> <4D668827.8060508@freedesktop.org> <1298567313.2814.7.camel@edumazet-laptop> <87sjvds2r7.fsf@cruithne.co.teklibre.org> <1298575769.2659.10.camel@edumazet-laptop> Content-Type: text/plain Organization: ComX Networks A/S Date: Fri, 25 Feb 2011 12:21:52 +0100 Message-Id: <1298632912.21810.33.camel@traveldev.cxnet.dk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Feb 2011 03:39:20 -0800 Cc: Van Jacobson , bloat-devel@lists.bufferbloat.net, herbert@gondor.apana.org.au, bloat@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 11:22:15 -0000 On Thu, 2011-02-24 at 20:29 +0100, Eric Dumazet wrote: > - Its important to set TSO off (ethtool -K eth0 tso off), or else we > send big packets (up to 64Kbytes) and this used to break SFQ fairness. > This can really hurt latencies of interactive flows. Don't you mean "GSO" Generic-Segmentation-Offload (ethtool -K eth0 gso off) as this happens in the stack. While TSO Tcp-Segmentation-Offload happens in hardware, and you will not see it in the SFQ qdisc? I recommend that both is turned off, on small bandwidth links where latency matters. I'm wondering if LRO (Large-Receive-Offload) affect you, when you are using SFQ on ingress? Recently had some "funny" issues with GRO, where a 100 Mbit/s customer could "only" get approx 90 Mbit/s throughput to our speed test server (other customers, in another appartment building could get approx 96 Mbit/s). The issue was resolved by disabling GSO on the speed test server. The theory is that some switch on the path cannot handle the bursts generated by GSO, which is max 64K (I think, correct me if I'm wrong). When adjusting buffer sizes, its important to take this bursty TCP behavior into account, which is created by both GSO and TSO. I'm not saying that the queue size needs to be above 64K. For smaller links, it might make sense to set it, significantly below 64K, to avoid a GSO enabled Linux machine to ramp up its window size, which makes it capable of bursting. -- Best regards Jesper Brouer ComX Networks A/S Linux Network Kernel Developer Cand. Scient Datalog / MSc.CS Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer