[Cake] overheads or rate calculation changed?

[Sebastian Moeller]

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
>long.

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
        Sebastian


>
>Cheers,
>
>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.