On 28 July 2018 19:53:58 CEST, Jonathan Morton <[email protected]> wrote: >>> Note that with the existing tc classifier stuff we already added to >>> Cake, we basically have this already (eBPF can map traffic to tin >and >>> flow however it pleases). >> >> Sorry, this just jostled in my brain now that I may be able to >implement member fairness today, based on what you wrote earlier in a >thread that I entirely missed: >https://lists.bufferbloat.net/pipermail/cake/2018-May/003811.html >> >> George posted an example of assigning packets to a tin: >https://lists.bufferbloat.net/pipermail/cake/2018-May/003809.html >> >> How does one send packets to a specific flow / queue? > >The trouble here is that there's only 8 tins max in Cake. At that >level selection is done with a linear search, which doesn't scale up, >but is efficient for N=8.
Yeah, but replacing that with an rbtree should be straight forward. > The flow mapping is hardcoded for speed >with no override hook, because no consumer needs custom mapping of this >sort. Getting this to work is probably the most work, actually. I guess the 'tc class' config would be the obvious way to do express this, API-wise. >Fixing these problems to make them more ISP-friendly necessarily makes >it less consumer-friendly. Hence the new project. Much code can be >reused. If more features are needed, perhaps... But for just adding more classes I don't actually think it has to impact the UX for the current use cases. The existing keywords could be retained and map to the same configs. -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
