From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 828073B2A4 for ; Thu, 29 Nov 2018 03:19:21 -0500 (EST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 457D7B1; Thu, 29 Nov 2018 09:19:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1543479560; bh=Go91SXOxQq5LuRdIYoPFYt/8Ujc8Gg2M/UYMtVSc2xc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=enY2Az6j6iDPfnb4lBMDx4OE79BZPRKuWbW386blesb9yCLecPAMM6sqreZrFdzQ7 7zygRJqoILBu8bKnEKbBDFMRtGbPpJcvxmiYVL5CsKjoq+ISxF5/CEREHJMYvVU9AI tTJYRp25iYwEjUNBYbZHJVNHyhYSnk5E0MetOVEs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4370BB0; Thu, 29 Nov 2018 09:19:20 +0100 (CET) Date: Thu, 29 Nov 2018 09:19:20 +0100 (CET) From: Mikael Abrahamsson To: Jonathan Morton cc: bloat In-Reply-To: Message-ID: References: <65EAC6C1-4688-46B6-A575-A6C7F2C066C5@heistp.net> <38535869-BF61-4FC4-A0FB-96E91CC4F076@ifi.uio.no> <87va4gwe74.fsf@taht.net> <7125B446-F2C4-45B3-B48C-8720B1E35776@gmail.com> 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] incremental deployment, transport and L4S (Re: when does the CoDel part of fq_codel help in the real world?) 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: Thu, 29 Nov 2018 08:19:21 -0000 On Thu, 29 Nov 2018, Jonathan Morton wrote: > I'd say the important bits are only slightly harder than doing the same with fq_codel. Ok, FQ_CODEL is way off to get implemented in HW. I haven't heard anyone even discussing it. Have you (or anyone else) heard differently? > I believe much of Cake's perceived CPU overhead is actually down to > inefficiencies in the Linux network stack. Using a CPU and some modest > auxiliary hardware dedicated to moving packets, not tied up in handling > general-purpose duties, then achieving greater efficiency with > reasonable hardware costs could be quite easy, without losing the > flexibility to change algorithms later. I need to watch the MT7621 packet accelerator talk at the most recent OpenWrt summit. I installed OpenWrt 18.06.1 on an Mikrotik RB750vGR3 and just clicked my way around in LUCI and enabled flow offload and b00m, it now did full gig NAT44 forwarding. It's implemented as a -j FLOWOFFLOAD iptables rule. The good thing here might be that we could throw unimportant high speed flows off to the accelerator and then just handle the time sensitive flows in CPU, and just make sure the CPU has preferential access to the media for its time-sensitive flow. That kind of approach might make FQ_CODEL deployable even on slow CPU platforms with accelerators because you would only run some flows through FQ_CODEL, where the bulk high-speed flows would be handed off to acceleration (and we guess they don't care about PDV and bufferbloat). -- Mikael Abrahamsson email: swmike@swm.pp.se