On Tue, Dec 11, 2018 at 12:23 PM Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Jonathan Morton <chromati...@gmail.com> writes: > > >> On 11 Dec, 2018, at 8:32 pm, Aaron Wood <wood...@gmail.com> 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...
I'm totally not sold on the need for set-associativity. Recently though, I started thinking about doing dynamic minimal perfect hashing, as most ip addresses (and for that matter, mac addresses) are pretty long term stable. If we can calculate a minimal perfect hash (see cmph for example) fairly rapidly set associativity goes away... (but I don't have huge hopes for it as yet) I'm also impressed with the early analysis of cobalt's AQM implementation. I would like very much, however, for a close look at how much ack-filtering would benefit wifi. and funding for next year is on my mind. Not sure how to wedge anything into nl.net's RFP, but... And then there's the class-e stuff busy, busy, busy. Fixing the internet never ends! > > -Toke > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
