Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	"cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Backporting 'tc class' support
Date: Sun, 15 Jul 2018 22:41:34 +0000	[thread overview]
Message-ID: <DD9895DD-3236-41DB-B502-AD7916C070A9@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <87wotw6yeo.fsf@toke.dk>

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]



> On 15 Jul 2018, at 21:23, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
> 
>>> On 15 Jul 2018, at 10:48, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>> 
>>> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>>> 
>>>>> On 14 Jul 2018, at 22:50, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>> 
>>>>> Now that CAKE has been accepted upstream, I figured it was a good time
>>>>> to backport the 'tc class' support. So I did, back to kernel v4.9.
>>>>> 
>>>>> This is in the master branch; anyone feel like testing? With this, the
>>>>> version of CAKE in the master branch should be identical to the version
>>>>> that will be in Linux 4.19 :)
>>>> 
>>>> I need the attached patch to get it to build on openwrt - it looks
>>>> like an include guard order thing.
>>> 
>>> Ah, right, thanks! Fixed in master :)
>> 
>> And now that I’ve run it, with Georgios’ help (I’ve never played with
>> tc filters before!) I’ve fallen over a wrinkle:
>> 
>> So using sqm-scripts I have my standard cake instances on eth0 and
>> ifb4eth0, both using diffserv3 <<— diffserv3 is important. This
>> creates according to tc -s qdisc Bulk, Best Effort & Voice tins.
>> (where is he going with this?)
>> 
>> For ‘fun’ I wanted to classify stuff incoming to my bittorrent port as
>> Bulk.  So you’d think that "tc filter add dev ifb4eth0 parent 8011:
>> protocol ip u32 match ip dport 6981 0xffff action skbedit priority
>> 8011:1” would do the trick.  8011:1 being the target tin.  Whilst
>> syntactically correct you’d be disappointed by the result
>> ‘cos…..diffserv3 & 4 put the bulk traffic in tin 2 although tc
>> displays it as the first tin.
> 
> Yeah, the tins are displayed in a different order than they are indexed.
> See the bulk_order and normal_order definitions. Basically, the first
> two are switched.
> 
> It's not actually obvious which is the right thing to do here? Use the
> classifier output as the tin index, or modify it by the tin order... In
> fact, I'm not quite sure what the purpose of the tin_order is in the
> first place…

IIRC in the old days tin 0 was always a 100% rate tin and bandwidth usage was charged to all lower tins, thus it would have been a bad idea to have bulk as being 100% rate, hence the swap for ‘bulk tin’ diffserv patterns.

That is no longer the case, see commits 423112e,  4f62bd1 and 008a276 at least :-)

AFAICT the tin order makes no difference whatsoever these days, indeed the dequeue mechanism picks up from the last tin and spins around rather than starting at either 0 or highest tin each time.

> 
> Jonathan, care to comment? :)
> 
> -Toke



[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2018-07-15 22:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-14 21:50 Toke Høiland-Jørgensen
2018-07-15  0:48 ` Kevin Darbyshire-Bryant
2018-07-15  9:48   ` Toke Høiland-Jørgensen
2018-07-15 20:13     ` Kevin Darbyshire-Bryant
2018-07-15 20:23       ` Toke Høiland-Jørgensen
2018-07-15 22:41         ` Kevin Darbyshire-Bryant [this message]
2018-07-16  2:09           ` Jonathan Morton
2018-07-16  4:00             ` Dave Taht
2018-07-16  9:24               ` Toke Høiland-Jørgensen
2018-07-16  9:30             ` Toke Høiland-Jørgensen
2018-07-16  9:57               ` Jonathan Morton
2018-07-16 10:18                 ` Toke Høiland-Jørgensen
2018-07-16 12:06                   ` Georgios Amanakis
2018-07-16 12:28                     ` Toke Høiland-Jørgensen
2018-07-16 12:44                       ` Kevin Darbyshire-Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DD9895DD-3236-41DB-B502-AD7916C070A9@darbyshire-bryant.me.uk \
    --to=kevin@darbyshire-bryant.me.uk \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=toke@toke.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox