[Cake] Backporting 'tc class' support

[Kevin Darbyshire-Bryant]

> On 15 Jul 2018, at 21:23, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
> 
>>> On 15 Jul 2018, at 10:48, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>> 
>>> Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> writes:
>>> 
>>>>> On 14 Jul 2018, at 22:50, Toke Høiland-Jørgensen <toke at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180715/5094ada9/attachment.sig>