From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B8FD43BA8E for ; Thu, 26 Apr 2018 04:43:54 -0400 (EDT) Received: by mail-io0-x229.google.com with SMTP id t23-v6so17160241ioc.10 for ; Thu, 26 Apr 2018 01:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LlrNX4po4NGpwpUgcx97PWcpGJqpyGTg04+r8wm08ck=; b=a15YzHyFoyNCk4T7g8S4zQTrjSTzgBqF41SEIvzNWHxk4a5A7Tx0WTsSQFjYF4Ffg2 Mk+RBbG3YerVWaDcat6AEIdc0OqUO1qyRHaQC9fz4R5/2bLXZYMFrOO1na0PZsOUnSYd 3NoOd8RjHLSMrxwNx4u+fAvnu18BIQHdHs0Kd6tiegLQFP2rSAcpjb7j7hnXYUfmExpZ ybjrTZYTO4VFRuKNtDhxynoB2gLVQS6tYKUg3ys7jULzyN/kXNMkO1OxBP+hJSTpCIkN DHXlx6zRJR/WIrtr8yE5eKUVMflv3rMJOmCBZEV30pVp7fowoCd1kqf9fVMIroNAtqK+ hhvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LlrNX4po4NGpwpUgcx97PWcpGJqpyGTg04+r8wm08ck=; b=RKaahKefXWYaxfBKNCjWt/eztDId8Ct3rOKZ8z97gUyJ0WLM7zSlaNjNcJEg4JLwc9 AhKFkZZgMJ43K+x4CwBjemoIpxEBtob1IxB/6DaGqn7E37ZZqr0UXCFQ3nSzxr0iLh2F 6hwb2CwMD1AEM0Nca6bHe+7Lh5jCiSP/u+O5lIKQsblWtgWThKle3lvwsgf7pUGnfpIJ 6X3ijkq09xpPBM3AhLqO9FADx3YepaA2kKRuhtVtKIZl2oJyaKXlERdewNrlfiAVE93c ponnjGQVuHhEVM1J3S2YeG6wh9FGk17DBgI5LBPqb/S3LWUTeE8S6BnUFm5w8Vrmy3MK RxWA== X-Gm-Message-State: ALQs6tAf5fm5dvidYzp9ZzH2GQGiRxLrTjC/yTFvnPhAsCMfxoWC/qv5 GkrLqm3qYtqpP6uDVCUASYA69paF/2b5Y1hA8x8= X-Google-Smtp-Source: AB8JxZqtqRejw1OvhLPTOmT35/6O+wwoQwM95pWwMUQpK4qrcerGPSoJIAn2MWkY7QGOcgxVl5AQZBefnFVI2QS1vlQ= X-Received: by 2002:a6b:a867:: with SMTP id r100-v6mr33033980ioe.143.1524732234119; Thu, 26 Apr 2018 01:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:52c8:0:0:0:0:0 with HTTP; Thu, 26 Apr 2018 01:43:53 -0700 (PDT) In-Reply-To: <87h8ny4e18.fsf@toke.dk> References: <87vacf3th7.fsf@toke.dk> <87h8ny4e18.fsf@toke.dk> From: =?UTF-8?Q?Jonas_M=C3=A5rtensson?= Date: Thu, 26 Apr 2018 10:43:53 +0200 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Kevin Darbyshire-Bryant , "cake@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="000000000000313e48056abc633a" Subject: Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 08:43:54 -0000 --000000000000313e48056abc633a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "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=C3=B8iland-J=C3=B8rgensen wrote: > Kevin Darbyshire-Bryant writes: > > >> On 25 Apr 2018, at 21:45, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> > >> For those who have not been following the discussion on the upstreamin= g > >> patches, here's an update: > >> > >> > >> > >> 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=E2=80=99ve sort of half been following the =E2=80=98discussion=E2=80= =99, as ever the > > reaction from the kernel people makes it a place I never wish to > > look/contribute, =E2=80=A6.. this from Eric has me disturbed "If you ke= ep > > saying this old urban legend, I will NACK your patch.I am tired of > > people pretending GSO/TSO are bad for latencies.=E2=80=9D > > 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=E2=80=99s lat= ency > > 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=E2= =80=99t > > split the super packet, surely I have to wait till the end of the > > superpacket=E2=80=99s queue (for want of a better word) and possibly ex= ceed my > > latency target. That looks to me like =E2=80=98GSO/TSO=E2=80=99 is pot= entially bad > > for interflow latencies. What don=E2=80=99t 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 > --000000000000313e48056abc633a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"I *think* that what Eric m= eans is=C2=A0that the GSO logic should aut= omatically size the GSO superpackets so the=C2=A0latency cost is negligible for the actual link rate."
Something like this?

=


/Jonas

On Thu, Apr 26, 2018 at 9:34 A= M, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Kevin Darbyshire-Bryant <<= a href=3D"mailto:kevin@darbyshire-bryant.me.uk">kevin@darbyshire-bryant.me.= uk> writes:

>> On 25 Apr 2018, at 21:45, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
>>
>> For those who have not been following the discussion on the upstre= aming
>> 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 whi= ch is a
> good sign.

Awesome!

> I=E2=80=99ve sort of half been following the =E2=80=98discussion=E2=80= =99, as ever the
> reaction from the kernel people makes it a place I never wish to
> look/contribute, =E2=80=A6.. 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.=E2=80=9D

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:=C2=A0 I have a superpacket circa 64K, this is a lump= of
> data in a tcp flow.=C2=A0 I have another small VOIP packet, it=E2=80= =99s latency
> sensitive.=C2=A0 If I split the super packet into individual 1.5K pack= ets
> as they would be on the wire, I can insert my VOIP packet at suitable<= br> > place in time such that jitter targets are not exceeded.=C2=A0 If I do= n=E2=80=99t
> split the super packet, surely I have to wait till the end of the
> superpacket=E2=80=99s queue (for want of a better word) and possibly e= xceed my
> latency target.=C2=A0 That looks to me like =E2=80=98GSO/TSO=E2=80=99 = is potentially bad
> for interflow latencies.=C2=A0 What don=E2=80=99t I understand here?
You are right in principle, of course. I *think* that what Eric mean= s 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

--000000000000313e48056abc633a--