Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: "Jonas Mårtensson" <martensson.jonas@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>,
	 "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed
Date: Thu, 26 Apr 2018 10:43:53 +0200	[thread overview]
Message-ID: <CAM9iV=J1c8m4ObdB0H1DgKdyMh1gjNQi91g_PRbUF_Q5+YY5nA@mail.gmail.com> (raw)
In-Reply-To: <87h8ny4e18.fsf@toke.dk>

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

"I *think* that what Eric means is that the GSO logic should automatically
size the GSO superpackets so the latency cost is negligible for the actual
link rate."

Something like this?

https://lwn.net/Articles/564979/

https://lwn.net/Articles/564978/

/Jonas

On Thu, Apr 26, 2018 at 9:34 AM, Toke Høiland-Jørgensen <toke@toke.dk>
wrote:

> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
> >> On 25 Apr 2018, at 21:45, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> >>
> >> For those who have not been following the discussion on the upstreaming
> >> patches, here's an update:
> >>
> >> <snip>
> >>
> >> So please do test the current git version (cobalt branch, still). I'm
> >> planning to resubmit on Friday.
> >
> > The two routers running that latest code survived the night which is a
> > good sign.
>
> Awesome!
>
> > I’ve sort of half been following the ‘discussion’, as ever the
> > reaction from the kernel people makes it a place I never wish to
> > look/contribute, ….. this from Eric has me disturbed "If you keep
> > saying this old urban legend, I will NACK your patch.I am tired of
> > people pretending GSO/TSO are bad for latencies.”
>
> Heh, yeah, the tone on kernel lists can be a bit... abrasive... just
> smile and wave and ignore the vitriol is my approach. But I can totally
> understand why some people don't want to put up with it... :)
>
> > Genuine question:  I have a superpacket circa 64K, this is a lump of
> > data in a tcp flow.  I have another small VOIP packet, it’s latency
> > sensitive.  If I split the super packet into individual 1.5K packets
> > as they would be on the wire, I can insert my VOIP packet at suitable
> > place in time such that jitter targets are not exceeded.  If I don’t
> > split the super packet, surely I have to wait till the end of the
> > superpacket’s queue (for want of a better word) and possibly exceed my
> > latency target.  That looks to me like ‘GSO/TSO’ is potentially bad
> > for interflow latencies.  What don’t I understand here?
>
> You are right in principle, of course. I *think* that what Eric means is
> that the GSO logic should automatically size the GSO superpackets so the
> latency cost is negligible for the actual link rate. I was actually
> thinking I would do some measurements at some point to test this at
> various rates; since we have a nice piece of code that can adaptively
> split GSO packets that should be pretty straight-forward :)
>
> -Toke
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

[-- Attachment #2: Type: text/html, Size: 5050 bytes --]

  reply	other threads:[~2018-04-26  8:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 20:45 Toke Høiland-Jørgensen
2018-04-26  1:10 ` Ryan Mounce
2018-04-26  1:32   ` Stephen Hemminger
2018-04-26  3:23     ` Dave Taht
2018-04-26  6:39   ` Toke Høiland-Jørgensen
2018-04-26  6:54     ` Ryan Mounce
2018-04-26  7:14       ` Toke Høiland-Jørgensen
2018-04-26  7:19 ` Kevin Darbyshire-Bryant
2018-04-26  7:34   ` Toke Høiland-Jørgensen
2018-04-26  8:43     ` Jonas Mårtensson [this message]
2018-04-26  8:55       ` Toke Høiland-Jørgensen
2018-04-26 12:02         ` Jonas Mårtensson
     [not found] ` <mailman.301.1524727201.3573.cake@lists.bufferbloat.net>
2018-04-26  7:26   ` Jonathan Morton
2018-04-26  7:43     ` Sebastian Moeller
2018-04-26 14:42       ` Jonathan Morton
2018-04-26 15:25         ` Sebastian Moeller
2018-04-27  0:17       ` David Lang
2018-04-26  8:16     ` 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='CAM9iV=J1c8m4ObdB0H1DgKdyMh1gjNQi91g_PRbUF_Q5+YY5nA@mail.gmail.com' \
    --to=martensson.jonas@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=kevin@darbyshire-bryant.me.uk \
    --cc=toke@toke.dk \
    /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