From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6CE003B2A4 for ; Fri, 17 Aug 2018 03:28:08 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DE0E7AF; Fri, 17 Aug 2018 09:28:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1534490886; bh=3wWhFdmGUy+tUPdFDCDHw1C4Rth/YyR+CqVHGhRKWOU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=O7IIQUAAUod2w+mfV2JEgNIGGBSdqWctCbgjcHdlRJVvJW2WikYr9IguTPzcy81h6 EIXh+EgJ85U0TKMfU8CC9G8ZOfDkIu/Zqy72EOV6kVdW3cbd+k76+E8vvSE52nTTup d4D4dVa0bNmV03EvHAYYA3X7+Iid7NtxzEApxAE0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D9F719F; Fri, 17 Aug 2018 09:28:06 +0200 (CEST) Date: Fri, 17 Aug 2018 09:28:06 +0200 (CEST) From: Mikael Abrahamsson To: Rosen Penev cc: dave.taht@gmail.com, bloat In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Bloat] Flow offload's impact on bufferbloat 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, 17 Aug 2018 07:28:08 -0000 On Fri, 10 Aug 2018, Rosen Penev wrote: > My question is not really how to fix it. I already know that. I just > got the feeling that bypassing parts of the linux network stack would > result in less buffering. On the OpenWrt configuration page for the "software flow offload": "Experimental feature. Not fully compatible with QoS/SQM." I don't know exactly what it does, it reduces amount of CPU cycles needed to forward packets in an already established flow it seems, but I'd imagine that it might very well bypass some of the scheduling code which could explain what you're seeing. So you might get faster forwarding but less AQM. So if your device isn't fast enough to keep up with your total Internet access speed, then this might be a good thing. If your device is faster than what's needed, then you'd better spend the cycles on getting good AQM instead of freeing up more CPU that isn't used for anything anyway. -- Mikael Abrahamsson email: swmike@swm.pp.se