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...
Best Regards
Sebastian
> On Dec 23, 2017, at 15:21, Sebastian Moeller <[email protected]> wrote:
>
> 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
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
