[Cake] overheads or rate calculation changed?

Sebastian Moeller moeller0 at gmx.de
Sun Dec 24 07:14:26 EST 2017

Hi Kevin,

On December 24, 2017 11:34:15 AM GMT+01:00, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>> On 23 Dec 2017, at 21:03, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Hi All,
>> just had a look for hard_header_len in the linux kernel:
>> linux/include/linux/netdevice.h:
>> *      @hard_header_len: Maximum hardware header length.
>> *      @min_header_len:  Minimum hardware header length
>> this seems to corroborate our observation that hard_header_len is not
>a veridical representation of the actual hardware header length, so I
>assume the values cake returns are actually true. It also indicates
>that except for pure ethernet interfaces hard_header_len is _not_ the
>right parameter to evaluate for what cake is evaluating it for...
>What came as a surprise to me the other day is that whatever ‘overhead’
>you specify on the command line must *include* the hard_header_len
>figure, since the code subtracts ‘hard header len’ from the passed
>overhead value.  I’ve probably been doing this wrong for… who knows how

Well, cake's motives were pure... Unfortunately it seems that the implementation just worked for Ethernet....
This behavior is also not terribly strongly advertized, probably a good thing with the currently exposed opportunities for further precision improvements.

>        if (tb[TCA_CAKE_OVERHEAD]) {
>if (tb[TCA_CAKE_ETHERNET])    <<<— this is really a synonym for ‘raw’,
>in my case it isn’t passed so else is exec
>              q->rate_overhead = -(nla_get_s32(tb[TCA_CAKE_ETHERNET]));
>                else
>q->rate_overhead = -(qdisc_dev(sch)->hard_header_len);     <<<—note the
>sneaky minus!
>                q->rate_overhead += nla_get_s32(tb[TCA_CAKE_OVERHEAD]);
>For a while I’ve manually been passing ’12’ as a ‘bridged-ptm
>ether-vlan’ equivalent except I should have been passing ’26’.  Instead
>I’ve been reducing the length of packets by 2 bytes :-)   I now just
>pass the relevant keywords.

The key words probably do not really save you... Plus the ptm accounting as done by cake is imprecise, or rather it is imprecise and incurres a (very small) per packet cost, while statically reducing the ptm bearer's synchrate by 100-100*64/65 at configuration time, is more precise and has 0 added per packet cost, but I digress.

Best Regards

>Kevin D-B
>Falling into traps so you don’t have to(tm)
>012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the Cake mailing list