From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BF7D43B2A4 for ; Thu, 26 Apr 2018 20:17:16 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id w3R0H8RN006719; Thu, 26 Apr 2018 17:17:08 -0700 Date: Thu, 26 Apr 2018 17:17:08 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Sebastian Moeller cc: Jonathan Morton , "cake@lists.bufferbloat.net" In-Reply-To: <51A5A6AB-4B1C-4795-8136-9EB63E59598B@gmx.de> Message-ID: References: <87vacf3th7.fsf@toke.dk> <46C6A124-61F3-4503-B310-C55D46597EED@gmail.com> <51A5A6AB-4B1C-4795-8136-9EB63E59598B@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-935490556-1524788228=:4538" 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: Fri, 27 Apr 2018 00:17:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-935490556-1524788228=:4538 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 26 Apr 2018, Sebastian Moeller wrote: >> On Apr 26, 2018, at 09:26, Jonathan Morton wrote: >> >>> 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 have it exactly right. For some reason, Eric is failing to consider the general case of flow-isolating queues at low link rates, and only considering high-rate FIFOs. >> >> More to the point, at 64Kbps a maximal GSO packet can take 8 seconds to clear, while an MTU packet takes less than a quarter second! > > I venture a guess that it is not so much the concept but rather the > terminology that irritates Eric? If at all Superpackets lighten the kernel's > load and will in all likelihood make in-kernel processing faster which if at > all decreases latency. The effect on flow fairness that we are concerned about > might simply not register under "latency" for the kernel developers; I am sure > they see the issue and this is really about which words to use to describe > this... Also I point at the fact that Eric did not object to the feature per > se, but rather the unconditionality and the rationale. Keep in mind that he was also griping about the focus on <100M bandwidth limits and talking about >10G links. At those speeds, the large GSO packet is not a significant factor. David Lang --680960-935490556-1524788228=:4538--