Re: [Cake] pleased to see some patches land for cake

[Jonathan Morton <chromatix99@gmail.com>]

> On 13 Apr, 2016, at 23:15, Dave Taht <dave.taht@gmail.com> wrote:
> 
> ... so I filed some bugs.

It should build on normal kernels now, as well as net-next.  I took advantage of the fact that the bug was filed against kernel 4.5.0, whereas net-next is on 4.6.0.

The flow counters now rest at zero when a tin is idle.  Previously they didn’t (since a queue is only retired when it is serviced while empty, and an empty tin never got that far), which was counter-intuitive.

I also made some small changes which should improve efficiency with Diffserv handling on.  These mostly revolve around increasing the quanta of the Diffserv DRR carousel.  The downside is that the Diffserv prioritisation won’t be quite as smooth, since it runs a single tin until the deficit is exhausted (or that tin is empty), which is the efficient way to do it.

Kevin noticed a small typo in the diffserv-llt setup code which was causing the instability I mentioned.  So that now works too.

I could add a diffserv3 mode quite easily at this point.  I looked at the Cisco stuff, though, and immediately got a headache.  I don’t think there’s a clean way to map that to Cake, and I don’t think we should try, either.

One of the LLT codepoints (Lo) is identical to the legacy “Max Reliability” TOS code.  The other (La) would be interpreted as a bizarre combination of the “Max Reliability” and “Min Delay” codes by legacy equipment, but is a valid combination under the original rules, which only forbid setting all three TOS bits at once.  I’m a bit surprised they didn’t simply reuse the existing “Min Delay” legacy code, which has the right intended meaning.  I mapped “La”, “Min Delay”, “EF” and “VA” to the “Low Delay” tin.

However, the other Diffserv modes in Cake don’t provide the specified LLT behaviour in any way.  The “low latency” tin(s) have a different priority (higher or lower, depending on its utilisation rate) to the best-effort/high-reliability tin(s), and often end up with *higher* values for the Codel parameters, due to their low threshold rates.  The best policy is therefore to leave “La” traffic in the best-effort tin, where it at least benefits from flow-isolation from best-effort traffic.

Meanwhile, I’m about to embark on a deep spelunking mission into one or more classful qdiscs’ code, to see whether I can write something to make Allan Pinto’s use-case (which sounds generally applicable for building-scale networks) work cleanly.  This would also be a good time to finally get around to writing a DSCP-remarking qdisc, so I might end up combining the two jobs into one.

 - Jonathan Morton