From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0AC8421F0D3 for ; Wed, 29 May 2013 16:18:29 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so9492732pdj.29 for ; Wed, 29 May 2013 16:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=acKO8NNnUns8dSl4h3h3xD9BgZgVpF2uWUAiuxuE620=; b=vWZ5jBvNRWs88k6uzgcu76NYzJaKQvReAy2iBTsSJLaRkZrQAh/hzepYzON3i1qs60 9b+znW2OW2pzyfQu+8DGxeJfe6cLkc4ucMeAWbBRtdUwhP/oPtMY9ArOOr35jWzNVPWF FPTBd5bgxvBuhsOjRHumzItidDgkB02wWDrwiB6A2mjdtICjY7WPMA4nf6Mg1tml7AGq L3zx2UYb2Fgf6OYBU5uOl6iok8O/BRRoleXlMXDR83+12abNob8Izt1HHpUrmqqUErZX JBaZN4e0dUeJFSDWDgHRh1JB9i5mDStWc0XM7O9cLXhr5UmWyw02di807z+Ygt9ephl+ PDSw== X-Received: by 10.68.171.226 with SMTP id ax2mr1639304pbc.201.1369869508620; Wed, 29 May 2013 16:18:28 -0700 (PDT) Received: from [172.29.163.116] ([172.29.163.116]) by mx.google.com with ESMTPSA id 10sm39064333pbm.0.2013.05.29.16.18.27 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 29 May 2013 16:18:28 -0700 (PDT) Message-ID: <1369869506.5109.87.camel@edumazet-glaptop> From: Eric Dumazet To: Stephen Hemminger Date: Wed, 29 May 2013 16:18:26 -0700 In-Reply-To: <20130529155034.334092c5@nehalam.linuxnetplumber.net> References: <20130529151330.22c5c89e@redhat.com> <1369842724.5109.44.camel@edumazet-glaptop> <20130529155034.334092c5@nehalam.linuxnetplumber.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Mike Frysinger , Jiri Benc , Jiri Pirko , netdev@vger.kernel.org, bloat@lists.bufferbloat.net, Patrick McHardy , Steven Barth , David Miller , Jussi Kivilinna , Felix Fietkau , Michal Soltys Subject: Re: [Bloat] tc linklayer ADSL calc broken after commit 56b765b79 (htb: improved accuracy at high rates) 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: Wed, 29 May 2013 23:18:29 -0000 On Wed, 2013-05-29 at 15:50 -0700, Stephen Hemminger wrote: > On Wed, 29 May 2013 08:52:04 -0700 > Eric Dumazet wrote: > > > On Wed, 2013-05-29 at 15:13 +0200, Jesper Dangaard Brouer wrote: > > > I recently discovered that the (traffic control) tc linklayer > > > calculations for ATM/ADSL have been broken by: > > > commit 56b765b79 (htb: improved accuracy at high rates). > > > > > > Thus, people shaping on ADSL links, using e.g.: > > > tc class add ... htb rate X ceil Y linklayer atm overhead 10 > > > > > > Will no-longer get ATM cell tax/overhead adjusted. > > > > > > How can we solve/fix this? > > > Perhaps we can change to use the "stab" system instead (as it does > > > not seem to be broken by the commit). > > > > > > But how do we facilitate a change to use "stab" system (for all the > > > scripts using the old option)? > > > > > > Can we change the iproute2/tc command to handle this transparently, or > > > should we give an error/warning if someone uses "tc" and "linklayer" on > > > a kernel above v.3.8. ? > > > > > > > > > History: > > > - My linklayer ATM changes appeared in kernel 2.6.24 (and iproute2 2.6.25) > > > - The STAB changes appeared in kernel 2.6.27 > > > > > > > Hi Jesper > > > > stab suffers from the same problem : its table driven, so works only for > > packet smaller than a given size. > > > > I am not sure it will solve the ATM logic (with the 5 bytes overhead per > > 48 bytes cell) > > > > btw, even on old kernels : > > > How bad is the failure? If it is fixed, will it break existing installations? > > Which probably means, is anyone but the original developers ever using it > and therefore likely to notice? Adding the logic on the kernel is doable, by adding some clean attributes so that tc can setup the feature, and report the attributes back. cpus are fast today and can perform the atm cell/overhead faster than a table lookup.