From nobody Tue May 6 15:06:54 2025 X-Original-To: dev-commits-src-main@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 4ZsMDz3BNcz5txNg; Tue, 06 May 2025 15:06:59 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsMDz0zJcz3bVd; Tue, 06 May 2025 15:06:59 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id CJ8uu53099JM2CJsnuoJ5F; Tue, 06 May 2025 15:06:57 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id CJsluxta0JhBPCJsmudUwI; Tue, 06 May 2025 15:06:57 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=QY3Fvdbv c=1 sm=1 tr=0 ts=681a2591 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=GljwOeMomgjytIAQ7p8A:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id E79E68FB; Tue, 06 May 2025 08:06:54 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id DEAF8300; Tue, 06 May 2025 08:06:54 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Gleb Smirnoff cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: d15792780760 - main - unix: new implementation of unix/stream & unix/seqpacket In-reply-to: <202505051956.545JuOPR085707@gitrepo.freebsd.org> References: <202505051956.545JuOPR085707@gitrepo.freebsd.org> Comments: In-reply-to Gleb Smirnoff message dated "Mon, 05 May 2025 19:56:24 +0000." List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 2025 08:06:54 -0700 Message-Id: <20250506150654.DEAF8300@slippy.cwsent.com> X-CMAE-Envelope: MS4xfHHO0xAqtcp0T65wQV6HiwOaecZuoGYLTy1xrow0fAdHYBijk0sC9Dh1sQq/LM/kYHOVBG1ffEtFnLOjr64gFOM0CS6k1u40h25fC0vO0PBsGYfUPdbi TOlDQu0yAIERX3tuCMtZa+t8LM/8DP0KrZDDFn8iicGF8KgcgVgijFIiHnZggqPQXgfyY8QbOSrdhy9fgw/r8PNo+yHWvsJ2XzRqcsUWMBwuhsb4iVn3U4KD yEGJIhexjNXB7qskiFLL0g8Ue/Iv6oaz17OoosRqwOtIO5AjV0MNe2u+M3SUpvwom5tjtFQKjoVPlbtkZFrl9GAYVr1H4Tr4baHFIpQqOv0= X-Rspamd-Queue-Id: 4ZsMDz0zJcz3bVd X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Spamd-Bar: ---- In message <202505051956.545JuOPR085707@gitrepo.freebsd.org>, Gleb Smirnoff wri tes: > The branch main has been updated by glebius: > > URL: https://cgit.FreeBSD.org/src/commit/?id=d15792780760ef94647af9b377b5f0a8 > 0e1826bc > > commit d15792780760ef94647af9b377b5f0a80e1826bc > Author: Gleb Smirnoff > AuthorDate: 2025-05-05 19:56:04 +0000 > Commit: Gleb Smirnoff > CommitDate: 2025-05-05 19:56:04 +0000 > > unix: new implementation of unix/stream & unix/seqpacket > > [this is an updated version of d80a97def9a1, that had been reverted] > > Provide protocol specific pr_sosend and pr_soreceive for PF_UNIX > SOCK_STREAM sockets and implement SOCK_SEQPACKET sockets as an extension > of SOCK_STREAM. The change meets three goals: get rid of unix(4) specifi > c > stuff in the generic socket code, provide a faster and robust unix/stream > sockets and bring unix/seqpacket much closer to specification. Highlight > s > follow: > > - The send buffer now is truly bypassed. Previously it was always empty, > but the send(2) still needed to acquire its lock and do a variety of > tricks to be woken up in the right time while sleeping on it. Now the > only two things we care about in the send buffer is the I/O sx(9) lock > that serializes operations and value of so_snd.sb_hiwat, which we can rea > d > without obtaining a lock. The sleep of a send(2) happens on the mutex of > the receive buffer of the peer. A bulk send/recv of data with large > socket buffers will make both syscalls just bounce between owning the > receive buffer lock and copyin(9)/copyout(9), no other locks would be > involved. Since event notification mechanisms, such as select(2), poll(2 > ) > and kevent(2) use state of the send buffer to monitor writability, the ne > w > implementation provides protocol specific pr_sopoll and pr_kqfilter. The > sendfile(2) over unix/stream is preserved, providing protocol specific > pr_send and pr_sendfile_wait methods. > > - The implementation uses new mchain structure to manipulate mbuf chains. > Note that this required converting to mchain two functions that are share > d > with unix/dgram: unp_internalize() and unp_addsockcred() as well as addin > g > a new shared one uipc_process_kernel_mbuf(). This induces some non- > functional changes in the unix/dgram code as well. There is a space for > improvement here, as right now it is a mix of mchain and manually managed > mbuf chains. > > - unix/seqpacket previously marked as PR_ADDR & PR_ATOMIC and thus treate > d > as a datagram socket by the generic socket code, now becomes a true strea > m > socket with record markers. > > - Note on aio(4). First problem with socket aio(4) is that it uses socke > t > buffer locks for queueing and piggybacking on this locking it calls > soreadable() and sowriteable() directly. Ideally it should use > pr_sopoll() method. Second problem is that unlike a syscall, aio(4) want > s > a consistent uio structure upon return. This is incompatible with our > speculative read optimization, so in case of aio(4) write we need to > restore consistency of uio. At this point we workaround those problems > on the side of unix(4), but ideally those workarounds should be socket > aio(4) problem (not a first class citizen) rather than problem of unix(4) > , > definitely a primary facility. > --- > sys/kern/uipc_usrreq.c | 1722 +++++++++++++++++++++++++++++++++++++--------- > -- > sys/sys/sockbuf.h | 12 + > 2 files changed, 1343 insertions(+), 391 deletions(-) > Is anyone else experiencing rsync hangs with this? I'm noticing rsync hangs with large files, like those in /usr/obj or a poudriere package repo. I haven't reverted this locally yet, just guessing ATM. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0