From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: "cake\@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed
Date: Thu, 26 Apr 2018 09:34:11 +0200 [thread overview]
Message-ID: <87h8ny4e18.fsf@toke.dk> (raw)
In-Reply-To: <C32790EA-B7C4-4B05-8185-8208C9233DB8@darbyshire-bryant.me.uk>
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
next prev parent reply other threads:[~2018-04-26 7:34 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 [this message]
2018-04-26 8:43 ` Jonas Mårtensson
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=87h8ny4e18.fsf@toke.dk \
--to=toke@toke.dk \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
/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