Hi Ryan,
> On Sep 5, 2017, at 16:37, Ryan Mounce <r...@mounce.com.au> wrote:
>
> On 5 September 2017 at 18:28, Sebastian Moeller <moell...@gmx.de> wrote:
>> Hi Kevin,
>>
>>
>>> On Sep 5, 2017, at 10:35, Kevin Darbyshire-Bryant
>>> <ke...@darbyshire-bryant.me.uk> wrote:
>>>
>>>
>>>
>>> On 05/09/17 09:01, Sebastian Moeller wrote:
>>> <snip>
>>>> I believe this is used internally so cake can deduce the size of the
>>>> automatically added overhead (the linux kernel will add 14 bytes on
>>>> ethernet interfaces automatically, which while certainly justifiable are
>>>> not the ideal value for an ethernet shaper); with this cake allows the
>>>> user to specify absolute overhead (so if you specify overhead 18, cake
>>>> will give you 14 - 14 + 18 = 18, while tc's stab method will give you 14 +
>>>> 18 = 32). So cake is doing the right thing here (the only thing it could
>>>> do even better is to report the size of the automatically corrected
>>>> in-kernel hard_header_len, but then the audience for that information is
>>>> probably to small to justify this feature).
>>>
>>>
>>> Actually for the sake of a one line change in the tc code it is an
>>> extremely useful confidence boost and info source as to just what linux
>>> thinks the overhead actually is:
>>>
>>> // This is actually the *amount* of automatic compensation,
>>> but we only report
>>> // its presence as a boolean for now.
>>> if (ethernet)
>>> - fprintf(f, "via-ethernet ");
>>> + fprintf(f, "via-ethernet(%d) ", ethernet);
>>>
>>> I've run that in a local patch to tc on LEDE for AGES. Very useful.
>>
>> That sounds like it would be a great addition, since the information
>> is already collected... For what it is worth I would vote for adding this...
>> (to the version that should be upstreamed ;) )
>
> +1
>
> It would also be nice for tc to know whether the overhead has been
> explicitly configured and report appropriately. In my case I use cake
> on a VLAN sub-interface that happens to have a hard_header_len of 18
> after the 802.1q tag, and then use the docsis keyword to more
> explicitly configure the overhead in case I move to an untagged
> interface in the future. tc -s qdisc can't tell the difference and
> reports 'raw mpu 64' rather than 'overhead 18 mpu 64'.
Ah, I see, when ever the explicitly requested overhead equals
hard_header_len, cake does not include it in its output. I believe this would
be nice to change to always explicitly report the overhead (so even default to
hard_header_len if no overhead was specified otherwise).
Since the keywords like docsis are really convenience wrappers (hace a look in
tc's q_cake.c) I vote for always expanding to the explicit overhead and
potentially MPU values instead of reporting the keyword used.
I believe manually specifying "overhead 18 mpu 64" will be just as future proof
as the docsis keyword in regards to changing hard_header_len.
It has to, in the end the docsis keyword gets interpreted by tc as:
/*
* DOCSIS cable shapers account for Ethernet frame with FCS,
* but not interframe gap nor preamble.
*/
} else if (strcmp(*argv, "docsis") == 0) {
atm = 0;
overhead += 18;
overhead_set = true;
mpu = 64;
Best Regards
Sebastian
>
>>
>> Best Regards
>> Sebastian
>>
>>
>>>
>>> Kevin
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
