[Cake] Using cake to shape 1000’s of users.

Dave Taht dave.taht at gmail.com
Sat Jul 28 14:07:48 EDT 2018


On Sat, Jul 28, 2018 at 10:54 AM Jonathan Morton <chromatix99 at gmail.com> 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.  The host/flow mapping is hardcoded for speed with no override hook, because no consumer needs custom mapping of this sort.

Ah. Sigh. I forgot that we only did tins, not queues (which is fraught
with peril). Do think that initial classifier could be entirely
bpf....

> Fixing these problems to make them more ISP-friendly necessarily makes it less consumer-friendly.  Hence the new project.  Much code can be reused.

It can be modeled with fq_codel for basic per-member fairness via the
prio field. Or drr. Or htb.

Meh, I'm leaning now towards a new qdisc (after benching the veth
approach which is more multicore, as cake is not multicore enough
presently)

here's an idea for qdisc name: isp. Come up with your own backronym.
integral sane provisioning.

>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619


More information about the Cake mailing list