From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B55443BA8E for ; Thu, 26 Apr 2018 03:34:16 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1524728053; bh=iT+aZ/j9fXn0zYlbA6G1+doySuOOVS1XgoZx5gM38rY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=N5EXTfqebprT0B0slUGRdo5nh6o5Q2eQ/d7uxl+uHJMjvsaoDIraxyD76aFnQtNHu /4Nj77x1xBti33tB2/ZYGADBnCPF9oQ3h9lAo4/lgBs9aGN/l0DUojULHi+oosNHHz hb1o3XUtiI+Zly5eYwhf2yDulULkiICl86lbDF9xExKRvc7DXMXyMPGoAVwdjaFtlP 9v5aoMCJieetDrFV5M7ZZNKHhbgiWowAaUMqwnDefiR9ceEYC1WWN+UcJ6iuEewJKm R1QjojdinY6k+pRtmJixyYu9QD4GArcOTIc1JMN5PYiP94FZPH+faxT3O6WeQ95Q9G OGywK48DFYsww== To: Kevin Darbyshire-Bryant Cc: "cake\@lists.bufferbloat.net" In-Reply-To: References: <87vacf3th7.fsf@toke.dk> Date: Thu, 26 Apr 2018 09:34:11 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h8ny4e18.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 07:34:16 -0000 Kevin Darbyshire-Bryant writes: >> On 25 Apr 2018, at 21:45, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> For those who have not been following the discussion on the upstreaming >> patches, here's an update: >>=20 >> >>=20 >> 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 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: 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 laten= cy > 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 exce= ed my > latency target. That looks to me like =E2=80=98GSO/TSO=E2=80=99 is poten= tially 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