From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 C241821F1D6 for ; Thu, 6 Jun 2013 07:28:08 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bi5so1786241pad.4 for ; Thu, 06 Jun 2013 07:28:08 -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=Dl3iV+JnDmR4/cWOtW3PScYxdqBirF7SW26PNama2yA=; b=AHPH9K/Z3BiY6mecGWiROUaLroXIgO78izw9W1/nrjuII3BgcRPPYVxn9Jq+OxDUIl Xp3OgfS1DL8P70mv7nhA0Q1a7WXQ9km91P84ithhvzRpdAerY5EY7HmytUy9R8zNmDHa JdrZYwd9ZFdpsCmqdgZiaA2Z88KThNJdfgzYJTcXZo6EHZK3d/ojTEIpWQE9fo4f49S5 rZB/QXV+6Xd6iQqRZnSYXRckGBRzPKR6hG+W4OZHS330zHja1dNmnzcG9c7rg3fjpvbO VXa3v8vumvh2k8O/0wpWyQC1cbaKT04fi5oeKQ5Ij+124b2yuro6bRV5PQCsg60/vza3 pqNg== X-Received: by 10.66.188.137 with SMTP id ga9mr39327938pac.9.1370528888148; Thu, 06 Jun 2013 07:28:08 -0700 (PDT) Received: from [172.19.246.80] ([172.19.246.80]) by mx.google.com with ESMTPSA id xe9sm5684703pbc.21.2013.06.06.07.28.06 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 06 Jun 2013 07:28:07 -0700 (PDT) Message-ID: <1370528885.24311.346.camel@edumazet-glaptop> From: Eric Dumazet To: Jesper Dangaard Brouer Date: Thu, 06 Jun 2013 07:28:06 -0700 In-Reply-To: <20130606155504.0eb6570a@redhat.com> References: <20130529151330.22c5c89e@redhat.com> <20130606155504.0eb6570a@redhat.com> 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] RFC: Proposed fix for tc linklayer 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: Thu, 06 Jun 2013 14:28:09 -0000 On Thu, 2013-06-06 at 15:55 +0200, Jesper Dangaard Brouer wrote: > Requesting comments. > > So, bacically commit 56b765b79 (htb: improved accuracy at high rates), > broke the "linklayer atm" handling. As it didn't update the iproute tc util. > > Treating this as a regression fix, this is the smallest and least > intrusive solution I could come up with. > > I'm basically restoring the "linklayer atm" handling, by using the > __reserved field in struct tc_ratespec, to convey the chosen > linklayer option. > > > KERNEL patch: > ============= > > [PATCH RFC] net_sched: restore "linklayer atm" handling > > From: Jesper Dangaard Brouer > > commit 56b765b79 ("htb: improved accuracy at high rates") > broke the "linklayer atm" handling. > > tc class add ... htb rate X ceil Y linklayer atm > > This patch restores the "linklayer atm" handling, by using the > __reserved field in struct tc_ratespec, to convey the choosen > linklayer option. > > This requires a corrosponding iproute2 tc fix, that updates this > field. Older tc binaries can be detected by the kernel, as the > field would be zero. > > Request-For-Comments-by: Jesper Dangaard Brouer > --- > > include/net/sch_generic.h | 8 +++++++- > include/uapi/linux/pkt_sched.h | 11 ++++++++++- > net/sched/sch_generic.c | 4 ++++ > 3 files changed, 21 insertions(+), 2 deletions(-) > > > diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h > index e7f4e21..c9916b1 100644 > --- a/include/net/sch_generic.h > +++ b/include/net/sch_generic.h > @@ -682,13 +682,18 @@ struct psched_ratecfg { > u64 rate_bps; > u32 mult; > u16 overhead; > + u8 linklayer; > u8 shift; > }; > > static inline u64 psched_l2t_ns(const struct psched_ratecfg *r, > unsigned int len) > { > - return ((u64)(len + r->overhead) * r->mult) >> r->shift; > + u64 pkt_len = len + r->overhead; > + > + if (r->linklayer == TC_LINKLAYER_ATM) > + pkt_len = DIV_ROUND_UP(pkt_len,48)*53; Is this working on 32bit kernel ? > + return (pkt_len * r->mult) >> r->shift; > } I have no idea why you include so many people on your mails. This looks like ATM link have real rate of 48/53 of the rate. Since we have to distribute a new tc version, why not doing "tc ... rate rate X ceil Y linklayer atm" -> "tc ... rate X*48/53 Y*48/53" It avoids hard coded values in the kernel. Or make it use STAB if people really want to count bits/cells instead of bytes. Lets try to keep this overhead out of the fast path.