Re: [Cerowrt-devel] fq_pie for linux
Toke Høiland-Jørgensen writes: > Dave Taht 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. (I'd rather like a setsockopt that sorted packets in the recv socket buffer and head-dropped... ) While trying to work entirely from memory, using things like queue.h's TAILQ macros... it ended up looking almost exactly like eric's code (because that's so perfect! :)) and what I really needed (for babel) was a version that was BSD-licensed. So I figured I'd look hard at the freeBSD version and try to write from that... or a hard look at cake... and never got back to it. I guess we could ask eric if he'd mind if we just ported fq_codel to userspace and relicensed. Wouldn't mind a go and rust version while we're at it... The only difference in what I wrote was that I never liked the "search all the queues on overload" bit in fq_codel and just did that inline. This looked to work well with the bulk dropper. > > -Toke > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] fq_pie for linux
On Thu, 6 Dec 2018, Dave Taht wrote: Toke Høiland-Jørgensen writes: Dave Taht 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
Re: [Cerowrt-devel] fq_pie for linux
On Thu, Dec 6, 2018 at 12:13 PM David Lang wrote: > > On Thu, 6 Dec 2018, Dave Taht wrote: > > > Toke Høiland-Jørgensen writes: > > > >> Dave Taht 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. Are you referring to recvmmsg? That's always been problematic (it would block), but I keep hoping it's been fixed. While I'm kvetching about udp and userspace, would love the equivalent of high and low watermarks to work. select can return when there is only 1 byte of space available and thus you have to retry until there's room for a packet. I'm totally incapable of writing such a thing. I find these bits of the kernel impenetrable. > > David Lang___ > 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
Re: [Cerowrt-devel] dlte
Toke Høiland-Jørgensen writes: > Mikael Abrahamsson writes: > >> On Tue, 4 Dec 2018, Dave Taht wrote: >> >>> I expect dave reed to comment, so I'll withhold mine for now >>> >>> https://kurti.sh/pubs/dLTE-Johnson-HotNets-2018.pdf >> >> When I read the first page I was hopeful, then unfortunately I got >> disappointed and just quickly scanned the rest. It's still tunneled and >> the same architecture, just more distributed. > > OK, now I read the paper, and I think you may have missed the part where > they say that they terminate the tunnelling at the AP and assign new IPs > whenever a client roams. So it's basically WiFi APs over the LTE > layer-2... Which is pretty cool, I think :) It's still based on the false optimism that users will ever get to own and control their own LTE AP. > > -Toke > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
