[Cake] overheads or rate calculation changed?

[Kevin Darbyshire-Bryant]

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

        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.

Cheers,

Kevin D-B
Falling into traps so you don’t have to(tm)

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20171224/754668ad/attachment.sig>