On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE interfaces, for both egress (hard_header_len = 26) and ingress via ifb (hard_header_len = 14). At least this issue had been offset by the double-overhead bug for a little while :)
Regards, Ryan Mounce On 23 December 2017 at 23:25, Sebastian Moeller <[email protected]> wrote: > >> On Dec 23, 2017, at 10:59, Andy Furniss <[email protected]> wrote: >> >> Sebastian Moeller wrote: >> >>>> qdisc cake 1: dev enp6s0 root refcnt 2 bandwidth 19690Kbit diffserv3 >>>> triple-isolate rtt 100.0ms noatm overhead 48 via-ethernet total_overhead >>>> 48 hard_header_len 14 >>> This looks like expected, the in-kernel overhead is added to the >>> specified overhead, just like in the past. I really really wished cake >>> would report the packet size before and _after_ its overhead addition >>> making sanity checking much easier. BTW tc's stab might be useful as an >>> external check... I also wonder whether the kernel's behaviour in regards >>> to ppp interfaces changed between kernel 4.4 and newer ones, I see the same >>> weirdness: >> >> FWIW my pppoe router/pvr/nas box is running 4.1.46. It's a bay-trail dc >> board and they are prone to cstate bug locks, which is why I'm not running >> anything newer! >> > > Thanks for saving me the experiments... > > Mmh, that would indicate that dev->hard_header_len might not be the relevant > variable, it might be necessary to look into the IP packets total length and > the reported packet/frame size to figure out what the kernel really added > (since the kernel addition should not change it might be enough to do this > only for the first IP packet and cache that value). > > Best Regards > Sebastian > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
