From nobody Wed Nov 10 01:57:20 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2ABED1852D1B for ; Wed, 10 Nov 2021 01:57:27 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: from panix.netmeister.org (panix.netmeister.org [IPv6:2001:470:30:84:e276:63ff:fe72:3900]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HpnzV1Snrz3jqD for ; Wed, 10 Nov 2021 01:57:26 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: by panix.netmeister.org (Postfix, from userid 1000) id 35B828586F; Tue, 9 Nov 2021 20:57:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2021; t=1636509440; bh=EVvqkaetRwc+vOQyND1yoEKIYGdF8X3XVg0Q4XXCIkc=; h=Date:From:To:Subject; b=EailJNAla3xAQGu92i59r4I4VT5/ZMONbRgc9fTLOTMEzaSIPOCU0D0wzu8StKKo1 a0isXMWlYuyT2vF8seNQ8zLqhr3RR2XGGnh517CwhpeYdas3zBY90r19qN3f8sOh4G 0igL7fSpYC3Ien4014vZE3olPfSFwly6CSFJBjsc= Date: Tue, 9 Nov 2021 20:57:20 -0500 To: freebsd-net@freebsd.org Subject: AF_UNIX socketpair dgram queue sizes Message-ID: <20211110015719.GY3553@netmeister.org> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.1 (2018-12-01) X-Rspamd-Queue-Id: 4HpnzV1Snrz3jqD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netmeister.org header.s=2021 header.b=EailJNAl; dmarc=pass (policy=quarantine) header.from=netmeister.org; spf=pass (mx1.freebsd.org: domain of jschauma@netmeister.org designates 2001:470:30:84:e276:63ff:fe72:3900 as permitted sender) smtp.mailfrom=jschauma@netmeister.org X-Spamd-Result: default: False [-1.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[netmeister.org:s=2021]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.980]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[netmeister.org:+]; DMARC_POLICY_ALLOW(-0.50)[netmeister.org,quarantine]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2033, ipnet:2001:470:30::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: jschauma@netmeister.org From: Jan Schaumann via freebsd-net X-Original-From: Jan Schaumann X-ThisMailContainsUnwantedMimeParts: N Hello, I'm trying to wrap my head around the buffer sizes relevant to AF_UNIX/PF_LOCAL dgram socketpairs. On a FreeBSD/amd64 13.0 system, creating a socketpair and simply writing a single byte in a loop to the non-blocking write end without reading the data, I can perform 64 writes before causing EAGAIN, yielding 1088 bytes in FIONREAD on the read end (indicating 16 bytes per datagram overhead). This is well below the total net.local.dgram.recvspace = 4096 bytes. I would have expected to be able to perform 240 1 byte writes (240 + 240*16 = 4080). Now if I try to write SO_SNDBUF = 2048 bytes on each iteration (or subsequently as many as I can until EAGAIN), then I can send one datagram with 2048 bytes and one datagram with 2016 bytes, filling recvspace as (2 * 16) + (2048 + 2016) = 4096. But at smaller sizes, it looks like the recvspace is not filled completely: writes in chunks of > 803 bytes will fill recvspace up to 4096 bytes, but below 803 bytes, recvspace is not maxed out. Does anybody know why smaller datagrams can't fill recvspace? Or what I'm missing / misunderstanding about the recvspace here? -Jan