From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4AB613B2A4 for ; Thu, 6 Apr 2017 08:14:13 -0400 (EDT) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id E2D0FB3886; Thu, 6 Apr 2017 14:14:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1491480850; bh=nQ/NvQnK/XzgSIbX9DBgeJU0Gg4+91f0UUTHni1T8QA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=hG77VxpqVgbu7GRn42cdu8EngWbdNf2jgWp8C40q6njr0dLu+RzVnwNBBuocVNgpT oZfnqiFAMYSbORR5xCeGtloy49Bl8Ksq8NuwS6bMl/fkcFwUAUGItku/KommFIYfjH fOHlp9Ep3I8Tt2ww5bFQwYf76lGE/ENcHFbuUDms9Ey0hwj3TVmMxnW33n4uB41VYh FgPoqbMvj+L6dmkhAfvafA6IHRozIXBw+R7UpJTniFeeprV7yoLgGG0yQtNm0C4/a3 2xWAji8ypidAQSmM+4RY7Ao9S4V7OOrSN/A1boP1Qabxv2XX/cDpL0C6shqHKH8P3o 0v/AF2WTJxhgg== Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 937FCC40276; Thu, 6 Apr 2017 14:14:10 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Pete Heist Cc: cake@lists.bufferbloat.net References: <2FD59D30-3102-4A3E-A38E-050E438DABF0@gmail.com> <87ziftubgy.fsf@alrua-kau> <8E96329F-A57D-49C7-A7EE-60BD165B4D5C@gmail.com> <87r315u7xe.fsf@alrua-kau> Date: Thu, 06 Apr 2017 14:14:10 +0200 In-Reply-To: (Pete Heist's message of "Thu, 6 Apr 2017 13:34:08 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mvbtu419.fsf@alrua-kau> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] flow isolation for ISPs X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:14:13 -0000 Pete Heist writes: > On Apr 6, 2017, at 12:50 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Pete Heist writes: > > The fq_codel qdisc does have support for arbitrary tc filters to replace > the default hashing, BTW. If you don't need the cake shaper, that might > be a solution? > > I see, I found mention of it in Chapter 6 of a draft RFC that it looks > like you wrote, actually > (https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06#section-6). :) > To try it out, am I heading the right direction by looking at tc > filter=E2=80=99s skbedit action, or is that just for MQ devices? > (http://man7.org/linux/man-pages/man8/tc-skbedit.8.html) > > I also saw this mention of =E2=80=9CWe are not aware of any deployments > utilising the custom classification feature" > https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-02#section-5.1.1, > so not sure how often this has been tried. :) > > Yeah, haven't actually heard of anyone using the feature in production. > It's basically this section from the 'classful qdiscs' section of 'man > tc': > > When a packet enters a classful qdisc it can be classified to one = of the classes within. Three criteria are available, although not all qdisc= s will use all three: > > tc filters > If tc filters are attached to a class, they are consulted f= irst for relevant instructions. Filters can match on all fields of a packet= header, as well as on the firewall mark applied by ipchains or iptables. > > So you can basically use the full capabilities of tc-filter in place of > the built-in hashing of fq_codel. The tc-u32 man page has some examples, > which is probably a good starting point. > > If you do try this out and feel like writing up a small > example/tutorial, I'm happy to add a link (or the whole thing) somewhere > on bufferbloat.net :) > > Sure, if I get it working I=E2=80=99ll include an example in my paper, Awesome! > but I=E2=80=99m still a little confused. Is fq_codel actually a classful > qdisc? Yup. The hash buckets are the classes, basically. You can get per-flow stats by doing `tc -s class show dev eth0` (only works when a flow has built a queue). > I get the part about matching with tc-filter and the u32 selector (as > intuitive as that is :), but am not sure of the action the filter > needs to take. However, I do see the example towards the bottom of the > tc-u32 man page where a hash table is created and filters move packets > into the right buckets. Perhaps it will be eventually decipherable > from this=E2=80=A6 :) The filter classifies a packet into a class. The 'minor number' of this is the queue number (so needs to be less than the number of flows you configured for fq_codel - 1024 by default). -Toke