<div dir="ltr">On Wed, Dec 5, 2018 at 11:51 PM Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> writes:<br>
<br>
> <a href="https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2" rel="noreferrer" target="_blank">https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2</a><br>
<br>
With all the variants of fq+AQM, maybe decoupling the FQ part and the<br>
AQM part would be worthwhile, instead of reimplementing it for each<br>
variant...<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div></div></div>