Hi Ryan,
> On Dec 23, 2017, at 14:11, Ryan Mounce <[email protected]> wrote: > > On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE > interfaces, That is the traditional indicator, that the kernel does not automatically add overhead for ppp interfaces, and that still seems valid. > for both egress (hard_header_len = 26) and ingress via ifb > (hard_header_len = 14). Yes, that matches what we saw before... > At least this issue had been offset by the > double-overhead bug for a little while :) I guess we need to retire the automatic adjustments the way they are done now and I will need to write an instruction how to deduce the applied overhead manually. That or I try to see whether my idea "compare the first IP packets skb->length with the value of its total length header field and report and correct for the difference between the two... But that requires some research first why the hard_header_len values for pppoe interfaces are as we see them (my hypothesis is that the kernel actually accounts for all known overheads for the whole interface stack (in my case pppoe-wan -> eth1.7 -> eth1) somehow) I guess I should have looked at the actual assumed kernel-added overhead earlier, but I only went as far as testing real ethernet interfaces. I maintain that if cake would report the max_len_with_overhead along with max_len this would have been way more prominent and easier to debug. Best Regards Sebastian > > 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
