From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 941183BA8E for ; Thu, 6 Dec 2018 15:21:14 -0500 (EST) Received: by mail-qt1-x843.google.com with SMTP id z16so2055698qtq.4 for ; Thu, 06 Dec 2018 12:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8WUqFnZp4Gy1OZFGeYdLzo6Bdn2RKuPMJ7QF5K2ezE8=; b=lagilEVSxK1oF1rdlzhWqD0AbQBJUtw3lZLrTUCumXqmTPugmTf5vvHOuTS7btGSXs /9YoOyA8RjHW12LglDSInnEKMmCBv1UXhi3vpNy5Cbuxy6Ii4kDJauKV1IE/JAexDOz/ nd3l95+Bs6Q5w0r4vLQiWZoxsYsikaJKqbb4RTbqYd4jM5DI/8On8hXB04Xmttee41hF aHB1u1GJ33L78E6ZJiE6cCC+6gvpLODdV84EdeZdIS5TexLT7Icox+Csx0U7sLJMW1DR G6Q/KVLa+hUzKEc3XADjsVjXfUszCVMwbIB3VZhiddpdMAHlG57Yg8bJ+waJnQc8EUVI LRBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8WUqFnZp4Gy1OZFGeYdLzo6Bdn2RKuPMJ7QF5K2ezE8=; b=t2aX9C8X5bsLiOR/qAeP42Vf8M4cuQp8h+oQr5XD0yQ/zXvV2XOjsglb7T56dpJM6g yKCWgF9b84egPsDYYpR/5XI61DEj/mwud4sHVKCchFuUGN0Ass2MKcIiAMUHtAD1sAOV 69Ca5YC4V1uuOyd0ZRKxgpoRy2s3J89OXD253ZPgDuJMVrdWVegM129Wy68IBKI13an7 /tp9zxf0iHleC5em3JgRcjATSacRdNT2txMsGoG4eNOtToSFeLpMVi4Rx0UD6zWRfERg CRC5pIWsx39GEGxqfbCK/J569sxN/Ac/bdFhK5JtN4MifLPMRnay6CFl0wgyoin5v1FS lfyA== X-Gm-Message-State: AA+aEWbinGRKXuHnOPeh20CVy73+RVhs/hGWHIwR/byEfiUg8ExaclGj KkEO59deUdA8iRg7s1PrKThNNtUfX3IK/exzBoA= X-Google-Smtp-Source: AFSGD/VRZ+QKLwKYvZQ1ezVc0NGufGVVXvZj0iX0vqqkUxQfv2bZHBOgkYeusI0Ftbj2Wvi1KRf6Ca2AcvUdtQxSWhU= X-Received: by 2002:a0c:aa56:: with SMTP id e22mr29496649qvb.158.1544127673996; Thu, 06 Dec 2018 12:21:13 -0800 (PST) MIME-Version: 1.0 References: <87bm5zgkkg.fsf@toke.dk> <87efau1kzp.fsf@taht.net> In-Reply-To: From: Dave Taht Date: Thu, 6 Dec 2018 12:21:01 -0800 Message-ID: To: David Lang Cc: =?UTF-8?Q?Dave_T=C3=A4ht?= , cerowrt-devel , Eric Dumazet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:21:14 -0000 On Thu, Dec 6, 2018 at 12:13 PM David Lang wrote: > > On Thu, 6 Dec 2018, Dave Taht wrote: > > > Toke H=C3=B8iland-J=C3=B8rgensen 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 pack= et > 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 --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740