* Re: [Cake] cake - first impression
2015-04-22 21:26 [Cake] cake - first impression Adrian Popescu
@ 2015-04-22 22:38 ` Jonathan Morton
0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Morton @ 2015-04-22 22:38 UTC (permalink / raw)
To: Adrian Popescu; +Cc: cake
> On 23 Apr, 2015, at 00:26, Adrian Popescu <adriannnpopescu@gmail.com> wrote:
>
> Cake is fast and seems to work, but there are some issues.
>
> tc doesn't allow setting the number of flows for cake:
>
> tc qdisc add dev eth0 root cake bandwidth 10mbit flows 2048
> What is "2048"?
> Usage: ... cake [ bandwidth RATE | unlimited ]
> [ besteffort | precedence | diffserv8 | diffserv4 ]
> [ flowblind | srchost | dsthost | hosts | flows ]
> [ atm ]
>
> bandwidth validation doesn't catch errors such as 100mbps:
> tc qdisc add dev eth0 root cake bandwidth 100mbps
> tc qdisc
> qdisc cake 8003: dev eth0 root refcnt 3 bandwidth 800Mbit diffserv4 flows
Firstly, tc delegates much of the qdisc configuration parsing to modules specialised for each qdisc. Helper callbacks are provided for parsing tricky items like rates and times (and for printing them) - so the interpretation of “mbps” as “megaBYTES per second”, versus “mbit” as “megaBITS per second" is entirely up to tc itself. The full range of such suffixes is therefore detailed in the tc manpage, and I have no inclination to artificially limit that.
Cake doesn’t support adjusting the number of queues per traffic class (yet), partly because we might want to set a different number for each class. As an extreme case, we could set just one queue for the bulk class, observing that fewer resources should be expended on a low-priority class. The “flows” keyword is provided as a way to restore the default FQ behaviour, using the entire 5-tuple rather than a subset or ignoring it completely.
On the other hand, there are potentially valid arguments for keeping the same number of queues in each class, not least that some ISPs use Diffserv in inappropriate ways, and that the overhead per queue is fairly low. The memory usage for queue housekeeping is in the kilobytes with the present settings, which is trivial on most modern hardware, and the algorithms are mostly O(1) on CPU under normal conditions; there’s an edge case or two which triggers an O(n) scan, but I think there’s a reasonable way to eliminate even that.
There may also be nuances to queue counts that we haven’t yet implemented and might complicate matters, such as a dual-layer FQ offering per-host fairness as well as per-flow fairness. Due to this uncertainty, and a strong desire to keep cake’s configuration simple, it’s a compile-time option only (ie. you have to edit the code).
Hence it’s a work in progress, albeit one that already works quite well.
- Jonathan Morton
^ permalink raw reply [flat|nested] 2+ messages in thread