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=k80D4uee; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 5FA625A061D for ; Thu, 23 Oct 2025 03:42:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1761183731; bh=VTgyofymhA90NCy66cUS/e2OkZBOj4wnXyAmyt3QIXg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=k80D4ueeWZbJMzAoHpQCNlFgzXG5HEwUTvMVkkx4PbkmMMAcRJ9fLXU4NQ3w2L8cy cFeULzi7P+m7771DoQ6ChjYgusCp3cnXr/9NwdKtZguz9JvltY5JALXVflzK3wzYVj T0R1e4SI87sFGQIICEMh/GtByiirgJ3jxV8z2IeTAZqXAPsViutCqMgf+aKzEFAfOT pwoIar9dSK5m1zmM5xqcG9xRcets1q8YV2HtbfBGrxdnl7QXvEbGRNnoY6OBzv0leO +E74E3kK3yD3yi5jcMj23wkEH+YFutqujPQTeEDOzA1uEx8+cOe4avYRkNL79hgkN0 ewwrmruutelmA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4csTKv1DBRz4wM2; Thu, 23 Oct 2025 12:42:11 +1100 (AEDT) Date: Thu, 23 Oct 2025 12:24:36 +1100 From: David Gibson To: Laurent Vivier Subject: Re: [PATCH v4 7/7] passt: Move main event loop processing into passt_worker() Message-ID: References: <20251017103129.229412-1-lvivier@redhat.com> <20251017103129.229412-8-lvivier@redhat.com> <997ad29f-4c62-495b-b4bf-7405dbc55537@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O0v7aSF1pQpdKCEO" Content-Disposition: inline In-Reply-To: Message-ID-Hash: 6RQUAKFCXV76EA6ATOSRE3NW5XIHOMKW X-Message-ID-Hash: 6RQUAKFCXV76EA6ATOSRE3NW5XIHOMKW 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: --O0v7aSF1pQpdKCEO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 22, 2025 at 08:49:38AM +0200, Laurent Vivier wrote: > On 22/10/2025 02:53, David Gibson wrote: > > On Tue, Oct 21, 2025 at 10:00:58AM +0200, Laurent Vivier wrote: > > > On 20/10/2025 03:43, David Gibson wrote: > > > > On Fri, Oct 17, 2025 at 12:31:29PM +0200, Laurent Vivier wrote: > > > > > Extract the epoll event processing logic from main() into a separ= ate > > > > > passt_worker() function. This refactoring prepares the code for f= uture > > > > > threading support where passt_worker() will be called as a worker= thread > > > > > callback. > > > > >=20 > > > > > The new function handles: > > > > > - Processing epoll events and dispatching to protocol handlers > > > > > - Event statistics tracking and printing > > > > > - Post-handler periodic tasks (timers, deferred work) > > > > > - Migration handling > > > > >=20 > > > > > No functional changes, purely a code restructuring. > > > > >=20 > > > > > Signed-off-by: Laurent Vivier > > > >=20 > > > > Looks good as far as it goes, and I've though often in the past that > > > > it would make more sense for the "engine" to go in its own function. > > > >=20 > > > > Wondering if it would make more sense to include the epoll_wait() > > > > itself and the loop in this function, rather than leaving that > > > > outside. > > > >=20 > > >=20 > > > When I introduce the multithreading and the multiqueue, as the thread= is > > > driven by the epollfd, the events are managed by the multiqueue part = and the > > > epollfd by the multithread part. > > >=20 > > > The "threading" worker is: > > >=20 > > > static void *threading_worker(void *opaque) > > > { > > > struct threading_context *tc =3D opaque; > > >=20 > > > while (true) { > > > struct epoll_event events[NUM_EPOLL_EVENTS]; > > > int nfds; > > >=20 > > > nfds =3D epoll_wait(tc->epollfd, events, NUM_EPOLL_E= VENTS, > > > TIMER_INTERVAL); > > > if (nfds =3D=3D -1 && errno !=3D EINTR) > > > die_perror("epoll_wait() failed"); > > >=20 > > > tc->worker(tc->opaque, nfds, events); > >=20 > > IIUC the point here is that eventually the epoll_wait() will be > > common, but the worker might be different for different threads. Is > > that correct? > >=20 >=20 > Yes, we can have the passt_worker() for all threads, but we can also have= a > specific worker for passt main (with netlink, listen, ...), a specific for > TX vhost-user (with kickfd), and another one for RX (with all the ICMP, U= DP, > TCP sockets). Ok. But do the different workers need to be different in their code, rather than just what fds end up in their epoll pool? I can see that there might be some worthwhile improvements to be had by specialising the worker functions. On the other hand, if we keep the worker loop generic, it would make it easier to refine our workload balancing by moving different fds between the threads. --=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 --O0v7aSF1pQpdKCEO Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmj5g9QACgkQzQJF27ox 2Gf9DRAApLveZAcl/ai4Tmh+m2hWTeW+UbIbiwgAUsPoTtCxgfHRSkPXBFYLcqk7 Tk3e73wfr+1+zUb/bgfjcuQ3aiIp9qVBC+diZxv6PEvIvYdoqIQrmWChKoe6+hN/ dQcDJlz81N5O+WMRcZ+8f/CzSwJPtcgTioS6/GvaM6XiHzCZV0lb/1vz96+FNGCk RSNqwZ6fFC9jWmZQhl+oZEeJR5cRdMC8HPcWmyM6jtddKeV9oDxbJ9aPM9Jpqubq elkEErD3bVMFHqOvox9/ljgrI2YvGL8Sx3/t9jGsAe710XqcpENJwFE26D13qAig u2rfqcD9ADWlKcIHgPi27W1/YnnCy85J7GSgeGsfRPgOPSWuktOPF1/2ykOAPHOt u8ZX7KKVHafTSUocm5QB5XHw6GzQojOKP7iYXqHdouAR2oA380uM4Y35DKnpH9NB exKwrpehvmKYmvzE9ripSPxQox2rdZaujjSAgMsx02Y+4ERjsRM48Io0CVmm7HWB Ml2lT4AgP9/EEDoc97nE5PbTugjpE4rRLjP8Nxzhf4msmjD9UDzhreTpow8INQeU FKIMaNcsJ+Yl6xzP/MBGOxDoVkEAnZMEpYWqhg15PQH+p35k8YmXKXx7Iqw+8o8S /Emmyi3+ZvHXtMV5sXmz2e5dNrS/Lqv5wr+3ddElRHznSBsVbMY= =Fvff -----END PGP SIGNATURE----- --O0v7aSF1pQpdKCEO--