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... -Toke _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
