> On 15 Jul 2018, at 21:23, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: > >>> On 15 Jul 2018, at 10:48, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >>> >>> Kevin Darbyshire-Bryant <ke...@darbyshire-bryant.me.uk> writes: >>> >>>>> On 14 Jul 2018, at 22:50, Toke Høiland-Jørgensen <t...@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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake