Hi Dave,
> On Dec 22, 2016, at 20:43, Dave Taht <[email protected]> wrote:
>
> 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
But does that matter? Is there really a hope that DSCPs will ever work
outside of a well controlled DS/cP-domain? Because inside one, you can make any
DSCP mean anything you want. Trusting ingress DSCPs to do the right thing
and/or be well enough conserved is a lottery ticket. And also trusting that the
right applications use the right ietf-compatible markings while no app tries to
abuse those seems optimistic. And finally to end-users the problem is not so
much which DSCP to priority bands/tier scheme was used, but rather how to
convince their important applications to actually mark their packets such.
> * We ignore the packet priority fields entirely
> * We don't know what diffserv models and ratios truly make sense
Well, IMHO that is a good indicator that making it configurable in
addition to a few well reasoned configuration seems not the worst thing to do,
no?
>
> 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
Why? At least it is a scheme that can be reasonably well described even
if it rarely will be a good match for what people want. What is does get right
IIRCC is sticking to half of the DSCP bits...
> * 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?
The ATM compensation itself is quite nice, the PTM compensation IMHO is
not doing the right thing (less precise and more computationally intensive than
required, even though by probably only little). I still have not become a
friend of the keywords (it does not help that at least one of them seems not on
accordance with the relevant ITU documents). Then again I am sure the keywords
do not need me as a friend. But all of this is optional and hence no
showstopper for merging (as long as none of them become default options
changing them later seems doable to me).
> * ipv6 nat?
The current believe seems to be that whoever does IPv6 NAT with a /128
and port remapping can keep the pieces. I have no idea how widespread such a
configuration actually is, and adding an option for that after upstreaming also
seems not unreasonable?
> * ipsec recognition and prioritization?
Why?
Best Regards
Sebastian
P.S.: The only part where I can claim some level of expertise (for a low value
of expertise) is the overhead accounting stuff, so take the rest with a smile.
> * 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.
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
