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=202510 header.b=y2UnQu7I; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id A9A065A061B for ; Wed, 08 Oct 2025 02:39:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1759883936; bh=YolTml7VQwuHmReAszEa85qZyx4HexedgaMPeiV1lqA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=y2UnQu7IH4Eg1G/AlY/0Kgl2YiwpOAtPOOPkqrLaWZNQ6MZms6QmY1iLw5sYhZ/JE 7+nIkd+5mOy0s3/IT043v+Rc8YYgTfi0URYh18jj/xiPZFOjGDGIzUOy6kictX7UoP hxzo8ui/80Av/CRiO5rdVM+0ZPjLkapiJ01bL6q9ZVidcQGe11lXWmPT38MbUV1E5k oU4vDlSqqUx/xChYzluxC1OiabLyqB/DrueHYxj1693T3SPOPRAdcnUvZuIz0iPCb0 n+UmO/83b1JVgi+tdEsYrUxnxD/WkW/6oQYdJ0LKsrZWwgIH21IUa/eHyETSG8IC7T VNn8bNADxH/+g== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4chDdr6SsGz4wCY; Wed, 8 Oct 2025 11:38:56 +1100 (AEDT) Date: Wed, 8 Oct 2025 11:12:03 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 3/5] tcp, flow: Replace per-connection in_epoll flag with epollfd in flow_common Message-ID: References: <20251003152717.2437765-1-lvivier@redhat.com> <20251003152717.2437765-4-lvivier@redhat.com> <20251007115117.3ba165a4@elisabeth> <20251007141503.1a79ae57@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7DihYF6rZ9bIoXaW" Content-Disposition: inline In-Reply-To: <20251007141503.1a79ae57@elisabeth> Message-ID-Hash: K4Q7W25QQUNQBWMJPSWKCNTU4AVGXV46 X-Message-ID-Hash: K4Q7W25QQUNQBWMJPSWKCNTU4AVGXV46 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: Laurent Vivier , passt-dev@passt.top 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: --7DihYF6rZ9bIoXaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 07, 2025 at 02:15:03PM +0200, Stefano Brivio wrote: > On Tue, 7 Oct 2025 14:07:39 +0200 > Laurent Vivier wrote: >=20 > > On 07/10/2025 11:51, Stefano Brivio wrote: > > > On Tue, 7 Oct 2025 17:07:37 +1100 > > > David Gibson wrote: > > > =20 > > >> On Fri, Oct 03, 2025 at 05:27:15PM +0200, Laurent Vivier wrote: =20 > > >>> The in_epoll boolean flag in tcp_tap_conn and tcp_splice_conn only = tracked > > >>> whether a connection was registered with epoll, not which epoll ins= tance. > > >>> This limited flexibility for future multi-epoll support. > > >>> > > >>> Replace the boolean with an epollfd field in flow_common that serve= s dual > > >>> purpose: zero indicates not registered (replacing in_epoll=3Dfalse)= , non-zero =20 > > >> > > >> Don't use 0, since that's a valid fd. > > >> =20 > > >>> stores the actual epoll fd (replacing in_epoll=3Dtrue). =20 > > >> > > >> I am a bit nervous about adding 31-bits to every flow, since I think > > >> we're fairly close to a cacheline threshold. =20 > > >=20 > > > I mentioned to Laurent in our weekly call on Monday the same concern > > > and that I would look into it (first step, I would say, actually check > > > with pahole?) and, if it's an issue, into possible tricks to avoid > > > making the struct too big. I still plan to do this. > >=20 > > I think it already doesn't fit in a cacheline: > >=20 > > struct flow_common { > > enum flow_state state:8; /* 0: 0 = 4 */ > > enum flow_type type:8; /* 0: 8 = 4 */ > >=20 > > /* Bitfield combined with next fields */ > >=20 > > uint8_t pif[2]; /* 2 = 2 */ > > struct flowside side[2]; /* 4 7= 2 */ > >=20 > > /* size: 76, cachelines: 2, members: 4 */ > > /* last cacheline: 12 bytes */ > > }; >=20 > Look at union flow, as we have an array of those, not flow_common. It's > two cachelines at the moment, we shouldn't go beyond that, and keeping > some margin would be nice as TCP might need some more bits > eventually. Right, I was unclear: it's going from 2 cachelines to 3 that I was concerned about. --=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 --7DihYF6rZ9bIoXaW Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjlrEMACgkQzQJF27ox 2GfkBg//RZsj/i2teqtw2toEIem+5uCTvQ0+lFnqylIH3mCiLGHOIClgYl7+sFWw d2Vbvj9HAM9edFU2vDqjlaeAVEcyx6wYKNGmXjc55hFFvPZzSewKjwVQd/gmaol4 4pTtMxBqtivtu55QhRL8KZz52fqVA4Pn1Y5rnijD8C2FjHMFGhKJhigoVZype0me 5uKABgpsaY1vv6nQLH8r4blXbWy4OHHyuyk5dRsog87BEN0OBTMSY/NdYjf8z7nu TODo2c/yYLPkaWWOzF4zFzip/OBaDYfg4sHuymQYC2tJYa5UOnyow1IbvY7z3mHL fFZIRlf8Vf0z/BV3cldqOz+u4LTlCIRbSGo8uxrBdxlVswU8ighWajpNQoSjx123 EzlTOU5y72K616g6owcoQGemsJkx1YYqJHixf+wbnXRVO0lwsJ2K8sfyjMAZ2+9B ysFz24OB/itAxfXhZRVhrvGmfZdc/mGMSTsILm9yDuoo+woMcOuP53++Ldc6QIzj kgihFkqnSXpDgiTmZp0WMnIAKB7h/zDRG8qA53g1TwCTsOf88BbfMao+AjCaMHch i+zWGJtZX9eymt4Drd37vZkTZS2+wEwKrzPtQWOl4dg3IiP7nr/YIhoVZFIkp2Ye V/Rum31zlBxtT2dNXMT1vrDKHCoBKbh+Nf0Q4PW7/uQm9TNBc18= =MxKy -----END PGP SIGNATURE----- --7DihYF6rZ9bIoXaW--