> On 23 Dec 2017, at 21:03, Sebastian Moeller <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
