Re: [Cake] upstreaming cake in 2017?

[Dave Taht <dave.taht@gmail.com>]

I have largely been focused on make-wifi-fast until the last week,
only doing a code review on cake over the last few days and submitting
a few patches thus far.

I have sometimes been frustrated enough on the squash/wash issue to
want to fork cake to "just do it", because RFC compliance actually
mandates that the traffic be re-marked appropriately upon transiting a
domain, and seeing CS1 enter my network from comcast really messes up
if it is passed directly through to wifi. It is far, far better to
squash on ingress, and to do it without a tc filter.

In other patches:

https://github.com/dtaht/sch_cake/pull/42 constifies things. (compile
tested only, btw)

And:

I was not aware of this "feature": https://github.com/dtaht/sch_cake/issues/41
until yesterday and it needs testing against real traffic, on real
RTTs. I think a lot of latency sensitive (and marked thus) traffic is
now pretty bursty (videoconferencing in particular, as well as
anything transiting a wifi hop beforehand) and (IMHO) the literature
on short queues is now invalid and out of date for all but voice
traffic. (that said, I'm willing to test first)

...

stats keeping seems broken: https://github.com/dtaht/sch_cake/issues/43

I have always been allergic to all the stats in the first place.
Keeping inaccurate stats is worse than no stats at all.

...

I will gladly re-roll a patch for squashing.

...

I would really like cake reviewed for suitability for mainlining
before it becomes part of lede's next release. In particular the
cobalt.*c* include has gotta go.

...

I've done a bit of profiling on it, basically cpu-wise it eats about
the same as htb+fq-codel does.