On Thu, 6 Dec 2018, Dave Taht wrote:
Toke Høiland-Jørgensen <t...@toke.dk> writes:
Dave Taht <dave.t...@gmail.com> writes:
https://github.com/gautamramk/FQ-PIE-for-Linux-Kernel/issues/2
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...
I actually sat down to write a userspace implementation of the fq bits
in C with a pluggable AQM a while back. I called it "drrp".
I think that there are many applications today that do too much
processing per packet, and end up with their recv socket buffer
overflowing (ENOBUFS) and tail-dropping in the kernel. I've certainly
seen this with babeld, in particular.
So by putting an intervening layer around the udp recv call to keep
calling that as fast as possible, and try to FQ and AQM the result, I
thought we'd get better fairness between different flows over udp and a
smarter means of shedding load when that was happening.
Then... there was all this activity recently around other approaches to
the udp problem in the kernel, and I gave up while that got sorted out.
one of these is (IIRC) mmreceive, which lets the app get all the pending packets
from the Linux UDP stack in one systemcall rather than having to make one
syscall per packet. In rsyslog this is a significant benefit at high packet
rates.
David Lang
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
