From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5476E3B2A4 for ; Fri, 27 Jan 2017 02:55:44 -0500 (EST) Received: from dair-2506.lorna-side.hm.taht.net (c-69-181-214-165.hsd1.ca.comcast.net [69.181.214.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id CABC821339 for ; Fri, 27 Jan 2017 07:55:42 +0000 (UTC) To: bloat@lists.bufferbloat.net References: From: =?UTF-8?Q?Dave_T=c3=a4ht?= Message-ID: <0496946b-827a-8527-643d-0b186f52e192@taht.net> Date: Thu, 26 Jan 2017 23:55:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Bloat] Recommendations for fq_codel and tso/gso in 2017 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 07:55:44 -0000 On 1/26/17 11:21 PM, Hans-Kristian Bakke wrote: > Hi > > After having had some issues with inconcistent tso/gso configuration > causing performance issues for sch_fq with pacing in one of my systems, > I wonder if is it still recommended to disable gso/tso for interfaces > used with fq_codel qdiscs and shaping using HTB etc. At lower bandwidths gro can do terrible things. Say you have a 1Mbit uplink, and IW10. (At least one device (mvneta) will synthesise 64k of gro packets) a single IW10 burst from one flow injects 130ms of latency. > > If there is a trade off, at which bandwith does it generally make more > sense to enable tso/gso than to have it disabled when doing HTB shaped > fq_codel qdiscs? I stopped caring about tuning params at > 40Mbit. < 10 gbit, or rather, trying get below 200usec of jitter|latency. (Others care) And: My expectation was generally that people would ignore our recommendations on disabling offloads! Yes, we should revise the sample sqm code and recommendations for a post gigabit era to not bother with changing network offloads. Were you modifying the old debloat script? TBF & sch_Cake do peeling of gro/tso/gso back into packets, and then interleave their scheduling, so GRO is both helpful (transiting the stack faster) and harmless, at all bandwidths. HTB doesn't peel. We just ripped out hsfc for sqm-scripts (too buggy), alsp. Leaving: tbf + fq_codel, htb+fq_codel, and cake models there. ... Cake is coming along nicely. I'd love a test in your 2Gbit bonding scenario, particularly in a per host fairness test, at line or shaped rates. We recently got cake working well with nat. http://blog.cerowrt.org/flent/steam/down_working.svg (ignore the latency figure, the 6 flows were to spots all over the world) > Regards, > Hans-Kristian > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >