From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C66813B29E for ; Tue, 11 Dec 2018 15:23:21 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1544559800; bh=rN7+Ylp8WAdPY19YB5YroE5gXxKDPhTq8oC9VnOnxM8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=O1FCrLcNUbZedquQFewRnbh0yqxvbhsMzNKo3AYQXWKQjAnFmRwnXfXUNTA+CJzaJ 26ELFiztAd0KoAyOCQxef5YP7lwwBC+B12Kr8WPyyybWjL1TRdapjUHgxNAualJMV2 +3g1e4w20uwjkdNq8A1g3tmo3lcao/soIFbFAo/hyL6gagSMPyNMH49VTyE5/Paw+e Z52KkFGZIFb0oWRAb6DEfggoQzhTMqYERb6m83ot0z0MSHgcJfKbYnz4vS2WDjFf/7 S/j9GCOAU7/PXWXFjSjeUPW9WbUvpoApw7F9s0Q6G63srwVIHnXWE2cBp+HZAYBJqx dVGfTNT488QOA== To: Jonathan Morton , Aaron Wood Cc: cerowrt-devel In-Reply-To: <1A5DC4D6-EAE7-4FE5-A553-A8989621907E@gmail.com> References: <87bm5zgkkg.fsf@toke.dk> <1A5DC4D6-EAE7-4FE5-A553-A8989621907E@gmail.com> Date: Tue, 11 Dec 2018 21:23:17 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o99rizii.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cerowrt-devel] fq_pie for linux X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:23:21 -0000 Jonathan Morton writes: >> On 11 Dec, 2018, at 8:32 pm, Aaron Wood wrote: >> >> With all the variants of fq+AQM, maybe decoupling the FQ part and the >> AQM part would be worthwhile, instead of reimplementing it for each >> variant... >> >> That's a great idea, Toke. There are a lot of places where I think it could work well, especially if it took a pluggable hash function for the hashing (at which point it's very general-purpose, and works on all sorts of different kinds of packets and workloads). That would let it be used for userspace VPN links (as an example), or within QUIC (or similar), where the kernel can't see the embedded flows that are hidden by the TLS encryption. >> >> And having it pluggable in the kernel would also allow IPSec to work >> without bloat (last I checked it was horribly bufferbloated, but that >> was ~5 years ago). > > I wonder if it's worth extracting the triple-isolate and > set-associative hash logic from Cake for this purpose? The interface > to COBALT is clean enough to be replaced by other AQMs relatively > easily. There's already a reusable FQ structure in the kernel (which is what the WiFi stack uses), which is partially modelled on Cake's tins. I had half a mind to try to have the two converge; Cake would shed some LOCs, and the WiFi stack could get set-associativity... -Toke