From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1DD313B29E for ; Fri, 27 Jul 2018 16:39:57 -0400 (EDT) Received: from localhost (unknown [172.56.44.110]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id E81A8102DFEA9; Fri, 27 Jul 2018 13:39:53 -0700 (PDT) Date: Fri, 27 Jul 2018 13:39:50 -0700 (PDT) Message-Id: <20180727.133950.685244782703142670.davem@davemloft.net> To: dave.taht@gmail.com Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net From: David Miller In-Reply-To: <1532659510-17385-1-git-send-email-dave.taht@gmail.com> References: <1532659510-17385-1-git-send-email-dave.taht@gmail.com> X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 27 Jul 2018 13:39:55 -0700 (PDT) Subject: Re: [Cake] [PATCH net-next] sch_cake: Make gso-splitting configurable from userspace 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 Jul 2018 20:39:57 -0000 From: Dave Taht Date: Thu, 26 Jul 2018 19:45:09 -0700 > I expect the first part of this patch to generate no controversy, > as being able to enable configure gso-splitting on or off in all > use cases of cake is a goodness. > > But: I expect the single line re-enabling cake's fielded default of > always splitting gro and gso packets, in shaped or unshaped mode, back > into packets, to reduce my email systems' hard disk inbox to a barren, > burnt cylinder, even if it is made easy to override thusly: > > tc qdisc replace dev whatever root cake no-split-gso > > While I agree that gro/gso is needed at 10gigE+ speeds, I feel > offering an option to disable splitting to those users trying to run > cake at those speeds is better than the alternative of forcing users > running at 1Gbit, 100mbit, 10mbit and below, with and without pause > frames, shaped or unshaped, to remember to split-gso. > > While I have assembled tons of data in use cases ranging from nearly 0 > to a gbit, the first, and most compelling argument I can make is > made in the commit that follows, where allowing GSO/GRO superpackets > triples the size of the underlying BQL when running at a gbit. I've applied this, we can revert it if there are strong objections.