From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202504 header.b=hJR7Y/wr; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 745105A026F for ; Fri, 25 Apr 2025 10:35:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202504; t=1745570149; bh=EwCGp4GIgXEzTMe3HE0al+/xshfZc4ucMgaeL8tbVMo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hJR7Y/wrCfdRV6DX/61omSHV0Y6er6dNu/HWl/YqiOEBE/ioiRrJQGAW2wmcYFWrt d3CZP5YdtGW+79K0nCJT+++sCEkdH6GD0rNSV1vz74WvMQe97/DsgHGxjnW9bO4gL9 Q2KU3LuZOrCLF0jioNFRfHfTI2tTY95Xd8F4d5LmviWqCECtHDECGjtnUkuwl8impw pAJytE5DUqIC+cr36ODV2PajQW+D3ruyOOfgjIU1ymQoObDDYgwCmGQ+Sh2NPZU+1x jhNGXetrXtaeV0PK+aLguZ8ZVzQZMrOp0LyR7rkmIgyj89eVRXEFN/yVCL/mi+pnYs biziLP5TeK/AA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4ZkR4j6LVFz4wbr; Fri, 25 Apr 2025 18:35:49 +1000 (AEST) Date: Fri, 25 Apr 2025 15:35:39 +0700 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 00/12] Use connect()ed sockets for both sides of UDP flows Message-ID: References: <20250404101542.3729316-1-david@gibson.dropbear.id.au> <20250425082700.0bbbf2a8@elisabeth> <20250425100706.5726013a@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WtKNhgDRQ1fZ5QY4" Content-Disposition: inline In-Reply-To: <20250425100706.5726013a@elisabeth> Message-ID-Hash: QBQ2SZRJS7EHNKOG3IVH6I7KXTDC2HMB X-Message-ID-Hash: QBQ2SZRJS7EHNKOG3IVH6I7KXTDC2HMB X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top, Jon Maloy X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --WtKNhgDRQ1fZ5QY4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 25, 2025 at 10:07:06AM +0200, Stefano Brivio wrote: > On Fri, 25 Apr 2025 13:49:26 +0700 > David Gibson wrote: >=20 > > On Fri, Apr 25, 2025 at 08:27:00AM +0200, Stefano Brivio wrote: > > > On Fri, 4 Apr 2025 21:15:30 +1100 > > > David Gibson wrote: > > > =20 > > > > As discussed, I've been working on using connect()ed sockets, rather > > > > than dups of the listening sockets for handling traffic on the > > > > initiating side of UDP flows. This improves consistency, avoids so= me > > > > problems (bug 103) and will allow for some useful future improvemen= ts. > > > >=20 > > > > It has the nice side effect of allowing some more code to be shared > > > > between various paths, resulting in a pretty nice negative diffstat. > > > >=20 > > > > David Gibson (12): > > > > udp: Use connect()ed sockets for initiating side > > > > udp: Make udp_sock_recv() take max number of frames as a parameter > > > > udp: Polish udp_vu_sock_info() and remove from vu specific code > > > > udp: Don't bother to batch datagrams from "listening" socket > > > > udp: Parameterize number of datagrams handled by > > > > udp_*_reply_sock_data() > > > > udp: Split spliced forwarding path from udp_buf_reply_sock_data() > > > > udp: Merge vhost-user and "buf" listening socket paths > > > > udp: Move UDP_MAX_FRAMES to udp.c > > > > udp_flow: Take pif and port as explicit parameters to > > > > udp_flow_from_sock() > > > > udp: Rework udp_listen_sock_data() into udp_sock_fwd() > > > > udp: Fold udp_splice_prepare and udp_splice_send into udp_sock_to= _sock > > > > udp_flow: Don't discard packets that arrive between bind() and > > > > connect() =20 > > >=20 > > > Just for the record: it's likely that something here made > > > https://github.com/containers/podman/issues/25959 more visible (or > > > directly caused it). I couldn't rule out recent ICMP changes yet, > > > but I'm fairly sure it's not those. =20 > >=20 > > Drat. I concur this series is the likely culprit. First place to > > check would be the error paths for a flow initiated from the host side > > (there are new ones because this now involves opening a new socket). > > Maybe we didn't clean something up in one of those cases leaving a > > bomb for a future allocation. >=20 > Right, either that, or perhaps the flow_defer_handler() loop setting > free_head to NULL if the UDP flow is (!closed) regardless of what > happened in the previous loop iterations... that looks a bit weird to > me. I'm pretty sure that's correct (and hasn't changed). free_head points to the first slot in the current "cluster" of free flow table slots. If it's NULL, we're not in a cluster of free slots, which indeed we're not if !closed - that indicates the current slot is (still) occupied. Setting it to NULL means we'll, correctly, start a new free cluster when we next encounter a free - or free-able - slot. --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --WtKNhgDRQ1fZ5QY4 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmgLSVoACgkQzQJF27ox 2Gdtwg//TtvCoZcRyCpbEGaSxd73Y5yCUmcok16bAsWuFXKgEF7YFNpa1eZnHfQL HFMKRtQGqqxSLkETX57cg1Z14Q/L2ElSSW35vOUQkWh4xko5MntoqiZr+SHFYVUd wPBQbtdUkNemQ8Pjjja1lQXBAJF4ICQqNUfoYdDdIpUVllHa5+pg2ZLVQfgjZntI Bn9RVBdmE8Ij0uFNuziUfdsW+AQlKYz37lUCBMuzCfqeA2xo/GDiB6QphYHq2s8A ++gyftbaGobeEQ6oMsx6Ten6FViJRvFsUPEQINU4zHXF8ElkRSuGRr6fM2/P1BKW MO4yLNprbO6RdDYuNmnEQz0HrB4tl22VrvxBrfh/mu8hz7/7j0dStvYriw30eBIy IPRRjjZ/ofLaahLXKxRDcZs4jMssO3f8N9ROD/DcHoweTCGcoXzSWZ39KrsIHw0k QqtckQHBIliGhwI1Nk0RKeRWGAuhBQ75dy5Za92NFePP08pVOE1LqgJYRLQUWC5W 2FinbSbup2E2DmochLoVyyzluGx3K+xJlmmTH2dswbcuTPGPYHAZPbiqd6NSD2S7 +ejhDej5BKzbe5zMuQzVTFd+I++tjIGrVDTbK5FhvIJtqZy96ocCHMJpG+WQYlMB /bKKuGi1+Sb6FlhUdo/5y2P/ZJFnqBbS73RTliTolUGihBmPy84= =i1Dn -----END PGP SIGNATURE----- --WtKNhgDRQ1fZ5QY4--