From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 346773B2A4 for ; Thu, 6 Apr 2017 10:55:10 -0400 (EDT) Received: from nemesis.taht.net (unknown [IPv6:2601:646:8501:df5:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 0ED9621434 for ; Thu, 6 Apr 2017 14:55:08 +0000 (UTC) From: Dave Taht To: bloat@lists.bufferbloat.net Date: Thu, 06 Apr 2017 07:55:07 -0700 Message-ID: <87bms9oab8.fsf@nemesis.taht.net> MIME-Version: 1.0 Content-Type: text/plain Subject: [Bloat] extending SO_SNDLOWAT and SO_RCVLOWAT to udp? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:55:10 -0000 I recently hit a several circumstances where it would have been nice to have SO_SNDLOWAT and SO_RCVLOWAT options working for udp (and netlink) sockets. In poking about the kernel it looks like these are implemented for TCP only. (?) I'm curious if anyone has tried to extend them to more socket types? It seems like it would be useful to have for things like QUIC in particular. NFS? I hit it 3 different ways: * select was returning a socket writable (because it had a byte available), but then EAGAIN when I tried to write a full size packet, so I went back to the select, which returned immediately so I went back to the EAGAIN.... * I completely flooded a multicast queue (11 minutes worth) - while that issue was in the driver, after I fix that, having some means of further backpressure up the stack would be good. * I actually wanted to have recvmmsg block til it had a few packets in it.