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=WSqzN84m; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id A621A5A026F 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=iWwvczbxfaxUSygpG1hlQhqY4cRgJkp8/Jp3nB1u1bg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WSqzN84mGIRfQLE3MzsBkmsbONSJvZ/pyP9yze9H5ZYyfVy8BQA+0noSmQsbop+oY XEaJUi6UoUJLqU0W4Pj6b84zNb8PdwIsiTBUeG23oOhjGTI5lhjn389VRQgRTph9kQ 8/VkPYnJ/xv52TrNkS3jJxNyY0ViYEgiV4C/r/fRwFiCwJqTuhg727VrDbYW1Mgp8H 1fvVr4H2SwznQVouL/bLwMnEd9YLz40u+Z+XvYH6mq6Ntm2LRrM20Hg4EGCrS10dds j3y1izK0m0T1THy5Mh1D7k02lrEMxMkzb6BoiGIV54eeA5C7awDBRQUENoU1IQYoe+ OE/sDgb1quybg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4chDdr6v76z4wCk; Wed, 8 Oct 2025 11:38:56 +1100 (AEDT) Date: Wed, 8 Oct 2025 11:24:35 +1100 From: David Gibson To: Laurent Vivier 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> <795ada45-d8ec-4ede-9b2e-54b5e1a50267@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EdF+vMOPEwGnQpse" Content-Disposition: inline In-Reply-To: <795ada45-d8ec-4ede-9b2e-54b5e1a50267@redhat.com> Message-ID-Hash: FOA7J7KU3GJ6IGVIFLLON7ZVJOPWQ3AY X-Message-ID-Hash: FOA7J7KU3GJ6IGVIFLLON7ZVJOPWQ3AY 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 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: --EdF+vMOPEwGnQpse Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 07, 2025 at 03:26:23PM +0200, Laurent Vivier wrote: > On 07/10/2025 08:07, David Gibson wrote: > > On Fri, Oct 03, 2025 at 05:27:15PM +0200, Laurent Vivier wrote: > > > The in_epoll boolean flag in tcp_tap_conn and tcp_splice_conn only tr= acked > > > whether a connection was registered with epoll, not which epoll insta= nce. > > > This limited flexibility for future multi-epoll support. > > >=20 > > > Replace the boolean with an epollfd field in flow_common that serves = 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 > > I'm not sure we really can add any less to flow_common, though, given > > alignment. > >=20 > > Then again... we probably don't need 8 bites each for TYPE and STATE, > > so those could be packed tighter. Then we could use a limited-bits > > index into a table of epollfds, rather than a raw fd. Much uglier, > > but maybe worth it? > >=20 >=20 > I tried the epollfds table. But it introduces complexity and a new shared > data structure that we will need to manage correctly in the case of > multithreading. I don't think it's the way to follow... I was assuming it would be a write-once data structure, meaning multithreaded management shouldn't be too hard. But ok. > The epollfds will be open at startup (we have already one: c->epollfd) and > their number will depend on the number of threads/queues (the maximum num= ber > of virtqueues for QEMU is 65536 but the number of queues is generally > configured to match the number of vCPU). And we can guess the file > descriptor will be allocated in order. So I think we can expect to fit in= an > 8-bit. Right, I guess it will. I don't love relying on that, but it's certainly an option. > In passt I'm setting the maximum number of virtqueues to 64, that > will limit also the number of epollfd. >=20 > Thanks, > Laurent >=20 >=20 --=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 --EdF+vMOPEwGnQpse Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmjlr0IACgkQzQJF27ox 2GeonQ/7B/MuYl7mGKK6PNro6HiU2HVaosCQnnfFe1LNxINuaWQEMSPqfHH4BUBQ 2MUIt4zejndeXO0MfWFf/dR6qNVth3CDYZRYzUIRKHxifh9HzGUIpy9PGLPqaKXL IM5ywv8JfOEs9jYJcccmuK5kCK8xUJ1PXu49LIpaOUBx7YoIJnx2LenNPobotz8X q28ROfVHF6kZi+tBrWRB+cLQP1cyEPwSSJ25vyRdXEfsyC4KLPGqpUArNAZx+YRi nnzmBOhcvPP8JnXrak6/codv0v/uUCkdNo3ejGDkiv60reEMeTZ4rRX5r+Pbq5Mj o2716MmI5+1zwJF1ljInN4d8zG5ySfmobWBr0F1E5WiyDyPacojhIuc8SKkIbCS6 0H8g76WUE9nOoIvBHU3C9QwN279EwgJeAybvkRBby5f3jhT2H7bhfYF9XbAahK1b 8CyIjds+rgZl6pqwB3AeRNuJhFxg+CAthN+TKWxzIXAmNGJd8wk+FOlVmQO1ESdL wqxtXpJ4SuV4IA/oEPi671eh3Roh1kBGQ/fBueP4ZpeD7OP0ND3XaTvd5u+JmPij R2USlLdWmWdrDYNvGIN5bU8PJz/D5SQCZB6Gois7qU7m7R8yx1mC1g50Rtforc7w HL9TATObu1/zxIZ6pDlw2pjotBDdQrKTdryoYvo07pNMdidk8as= =yync -----END PGP SIGNATURE----- --EdF+vMOPEwGnQpse--