[Cake] upstreaming cake in 2017?

Y intruder_tkyf at yahoo.fr
Fri Dec 30 02:42:09 EST 2016


Hi , I am yutaka.

I want to use cake codel without ECN.

bye bye :)

2016-12-22 (木) の 11:43 -0800 に Dave Taht さんは書きました:
> I think most of the reasons why cake could not be upstreamed are now
> on their way towards being resolved, and after lede ships, I can't
> think of any left to stop an
> upstreaming push.
> 
> Some reasons for not upstreaming were:
> 
> * Because the algorithms weren't stable enough
> * Because it wasn't feature complete until last month (denatting,
> triple-isolate, and a 3 tier sqm)
> * Because it had to work on embedded products going back to 3.12 or
> so
> * Because I was busy with make-wifi-fast - which we got upstream as
> soon as humanly possible.
> * Because it was gated on having the large tester base we have with
> lede (4.4 based)
> * Because it rather abuses the tc statistics tool to generate tons of
> stats
> * Because DSCP markings remain in flux at the ietf
> * We ignore the packet priority fields entirely
> * We don't know what diffserv models and ratios truly make sense
> 
> Anyone got more reasons not to upstream? Any more desirable features?
> 
> In looking over the sources today I see a couple issues:
> 
> * usage of  // comments and overlong lines
> * could just use constants for the diffserv lookup tables (I just
> pushed the
>    revised gen_cake_const.c file for the sqm mode, but didn't rip out
> the
>    relevant code in sch_cake). I note that several of my boxes have
> 64
> hw queues now
> * I would rather like to retire "precedence" entirely
> * cake cannot shape above 40Gbit (32 bit setting). Someday +40Gbit is
> possible
> * we could split gso segments at quantum rather than always
> * could use some profiling on x86, arm, and mips arches
> * Need long RTT tests and stuff that abuses cobalt features
> * Are we convinced the atm and overhead compensators are correct?
> * ipv6 nat?
> * ipsec recognition and prioritization?
> * I liked deprioritizing ping in sqm-scripts
> 
> Hardware mq is bugging me - a single queued version of cake on the
> root qdisc has much lower latency than a bql'd mq with cake on each
> queue and *almost* the same throughput.
> 


More information about the Cake mailing list