Re: [Cake] Cake3 - source code and some questions

[Jonathan Morton <chromatix99@gmail.com>]

> On 16 Apr, 2015, at 15:14, Adrian Popescu <adriannnpopescu@gmail.com> wrote:
> 
> Will the changes to codel made by cake be put into fq_codel?

This might be a more complex question than you realise.

The most likely feature of cake to be implemented in fq_codel might be the set-associative hash, since it’s almost a pure win.  That would almost be a cut-and-paste operation, but due to fq_codel’s de-facto status as a “standard candle” in research, it would need to be made configurable, at least to make turning it off easy.  And that isn’t really a “codel” feature change, since it influences the FQ layer exclusively.

The codel parameter tuning done by cake isn’t applicable to fq_codel, because the bandwidth information that this tuning relies on isn’t available (not even when it’s stacked with HTB).  That’s why cake defaults to something very like the standard codel parameters when the internal shaper is disabled (“unlimited” mode), and that in turn is one reason why those defaults are also used at "sufficiently high” bandwidths, so that there isn’t a sharp discontinuity in the behaviour when the bandwidth is increased beyond the link rate and on to infinity (unlimited mode actually works by setting the shaper to infinite bandwidth, ie. zero time per byte).  The other reason, as I previously noted, is because the parameters depend on the total RTT as well as the packet rate.

Which leaves algorithmic changes to codel itself.  It’s certainly possible to drop these (fairly subtle) changes in, but we should probably spend some more time measuring the effects of these changes and finalising them.  We’re considering doing a major refactor of the code, which might make it harder to perform a drop-in replacement.  In any case, FQ does mean that codel’s precise behaviour is less critical than it might otherwise be, and there are valid arguments - such as the “standard candle” one - for leaving it alone.

 - Jonathan Morton