Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Dave Taht <dave.taht@gmail.com>, Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] making split_gso_threshold configurable
Date: Wed, 25 Jul 2018 12:02:09 +0200	[thread overview]
Message-ID: <87effr3a72.fsf@toke.dk> (raw)
In-Reply-To: <CAA93jw6p=5oX63sDX=oDkEN_M3yOEVXgVDbUvOe-Xfpy-BCzCQ@mail.gmail.com>

Dave Taht <dave.taht@gmail.com> writes:

> I really wanted cake to always optimize for low latency. I wanted it
> to "just work" at line rate on dsl, on 100mbit, even 10mbit ethernet,
> to work against pause frames, etc, without configuration. I wanted to
> defeat drivers like the mvneta that can do 64k of software GRO
> automagically.

So I think that Eric's point was that the GSO logic itself should
throttle back and not build so big packets when the link rate is lower.
Might be worth it to check if this is actually the case, and if not to
get GSO fixed rather than disabling it.

Also, are there actually any modems that will negotiate ethernet line
rates less than a gigabit?

> Along the way to mainlining it, cake's behavior got changed, to scale
> well to 50Gbit by allowing GSO above a 1gbit shaped rate, and *always
> allowing GSO at line rate*.
>
>         if (q->rate_bps && q->rate_bps <= CAKE_SPLIT_GSO_THRESHOLD)
>                 q->rate_flags |= CAKE_FLAG_SPLIT_GSO;
>         else
>                 q->rate_flags &= ~CAKE_FLAG_SPLIT_GSO;
>
> I don't care about 50gbit. I'm delighted, even astonished, it does
> 50Gbit. I want it to do 1mbit with 13ms interpacket latency when hit
> by an IW10 burst from somewhere else, not 130, with hardware pause
> frames in use on the dsl modem or elsewhere.

Getting pause frames to work properly in this setup kinda requires the
buffering in the modem to be reasonable in the first place...

> so, I'd like to A) default to always split shaped or unshaped. And B)
> expose the split threshold to be configured via userspace. This latter
> option would give a tunable for those struggling a bit for cpu to play
> with, also.

I very much doubt that we can get upstream to accept split as the
default. It may be possible to get it to be user tunable. I don't think
we should deviate from upstream unless we absolutely have to (that was
kinda the whole point of the upstreaming exercise), and I'm not
convinced that this is a good enough reason...

-Toke

  reply	other threads:[~2018-07-25 10:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25  3:34 Dave Taht
2018-07-25 10:02 ` Toke Høiland-Jørgensen [this message]
2018-07-25 10:07   ` Sebastian Moeller
2018-07-25 16:00     ` Dave Taht
2018-07-25 22:12       ` Toke Høiland-Jørgensen

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=87effr3a72.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /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