From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (h-66-167-227-145.lsan.ca.dynamic.globalcapacity.com [66.167.227.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3F2623BA8E for ; Thu, 6 Dec 2018 15:13:38 -0500 (EST) Received: from asgard.lang.hm (syslog [10.0.0.100]) by mail.lang.hm (Postfix) with ESMTP id CC80A45051; Thu, 6 Dec 2018 12:13:34 -0800 (PST) Date: Thu, 6 Dec 2018 11:13:26 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht cc: =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= , edumazet@google.com, cerowrt-devel In-Reply-To: <87efau1kzp.fsf@taht.net> Message-ID: References: <87bm5zgkkg.fsf@toke.dk> <87efau1kzp.fsf@taht.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1636410054-1544123606=:22661" Subject: Re: [Cerowrt-devel] fq_pie for linux X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 20:13:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1636410054-1544123606=:22661 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT 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 --680960-1636410054-1544123606=:22661--