On Thu, 6 Dec 2018, Dave Taht wrote:

> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>> Dave Taht <dave.taht@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