Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Ryan Mounce <ryan@mounce.com.au>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>,
	cake@lists.bufferbloat.net
Subject: Re: [Cake] overhead and mpu
Date: Wed, 6 Sep 2017 00:07:49 +0930	[thread overview]
Message-ID: <CAN+fvRYp+bbvKZGp5AQ05_wSOg+9hjSEkMVU-A1HQJGJXodppA@mail.gmail.com> (raw)
In-Reply-To: <538A474A-8A75-4909-A386-2095817D4D0D@gmx.de>

On 5 September 2017 at 18:28, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Kevin,
>
>
>> On Sep 5, 2017, at 10:35, Kevin Darbyshire-Bryant <kevin@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'.

>
> 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

  reply	other threads:[~2017-09-05 14:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05  2:46 Dennis Fedtke
2017-09-05  3:26 ` Ryan Mounce
2017-09-05  3:37   ` Ryan Mounce
2017-09-05  6:00 ` Dennis Fedtke
2017-09-05  6:49   ` Ryan Mounce
2017-09-05  6:58   ` Jonathan Morton
2017-09-05 20:19     ` Dennis Fedtke
2017-09-06  1:45       ` Ryan Mounce
2017-09-06  7:26         ` Sebastian Moeller
2017-09-07  4:11           ` Dennis Fedtke
2017-09-07  4:18             ` Dennis Fedtke
2017-09-07  4:25               ` Jonathan Morton
2017-09-07  7:41                 ` Dennis Fedtke
2017-09-07  7:58                 ` Sebastian Moeller
2017-09-07  7:47             ` Sebastian Moeller
2017-09-07  7:58               ` Dennis Fedtke
2017-09-07  8:07                 ` Sebastian Moeller
2017-09-06  7:22       ` Sebastian Moeller
2017-09-05  8:01   ` Sebastian Moeller
2017-09-05  8:35     ` Kevin Darbyshire-Bryant
2017-09-05  8:58       ` Sebastian Moeller
2017-09-05 14:37         ` Ryan Mounce [this message]
2017-09-05 15:06           ` Sebastian Moeller
2017-09-05 15:33           ` Kevin Darbyshire-Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN+fvRYp+bbvKZGp5AQ05_wSOg+9hjSEkMVU-A1HQJGJXodppA@mail.gmail.com \
    --to=ryan@mounce.com.au \
    --cc=cake@lists.bufferbloat.net \
    --cc=kevin@darbyshire-bryant.me.uk \
    --cc=moeller0@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox