From: Laurent Vivier <lvivier@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v4 7/7] passt: Move main event loop processing into passt_worker()
Date: Tue, 21 Oct 2025 10:00:58 +0200 [thread overview]
Message-ID: <997ad29f-4c62-495b-b4bf-7405dbc55537@redhat.com> (raw)
In-Reply-To: <aPWTpg0W6m9RbArk@zatzit>
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 separate
>> passt_worker() function. This refactoring prepares the code for future
>> threading support where passt_worker() will be called as a worker thread
>> callback.
>>
>> 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
>>
>> No functional changes, purely a code restructuring.
>>
>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>
> 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.
>
> Wondering if it would make more sense to include the epoll_wait()
> itself and the loop in this function, rather than leaving that
> outside.
>
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.
The "threading" worker is:
static void *threading_worker(void *opaque)
{
struct threading_context *tc = opaque;
while (true) {
struct epoll_event events[NUM_EPOLL_EVENTS];
int nfds;
nfds = epoll_wait(tc->epollfd, events, NUM_EPOLL_EVENTS,
TIMER_INTERVAL);
if (nfds == -1 && errno != EINTR)
die_perror("epoll_wait() failed");
tc->worker(tc->opaque, nfds, events);
}
return NULL;
}
And the passt worker is registered with:
threading_worker_set(0, passt_worker, NULL, &c);
where:
int threading_worker_set(unsigned int threadnb,
void (*worker)(void *, int, struct epoll_event *),
bool (*is_valid)(void *, unsigned int criteria),
void *opaque)
{
struct threading_context *tc;
if (threadnb >= ARRAY_SIZE(threads))
return -1;
tc = &threads[threadnb];
tc->worker = worker;
tc->is_valid = is_valid;
tc->opaque = opaque;
return 0;
}
Thanks,
Laurent
next prev parent reply other threads:[~2025-10-21 8:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 10:31 [PATCH v4 0/7] Refactor epoll handling in preparation for multithreading Laurent Vivier
2025-10-17 10:31 ` [PATCH v4 1/7] util: Simplify epoll_del() interface to take epollfd directly Laurent Vivier
2025-10-17 10:31 ` [PATCH v4 2/7] epoll_ctl: Extract epoll operations Laurent Vivier
2025-10-17 11:48 ` Stefano Brivio
2025-10-17 12:21 ` Laurent Vivier
2025-10-17 13:05 ` Stefano Brivio
2025-10-20 1:20 ` David Gibson
2025-10-21 11:52 ` Laurent Vivier
2025-10-22 0:58 ` David Gibson
2025-10-17 10:31 ` [PATCH v4 3/7] util: Move epoll registration out of sock_l4_sa() Laurent Vivier
2025-10-17 10:31 ` [PATCH v4 4/7] tcp, flow: Replace per-connection in_epoll flag with threadnb in flow_common Laurent Vivier
2025-10-17 17:43 ` Stefano Brivio
2025-10-21 13:13 ` Laurent Vivier
2025-10-20 1:34 ` David Gibson
2025-10-21 12:14 ` Laurent Vivier
2025-10-22 1:00 ` David Gibson
2025-10-17 10:31 ` [PATCH v4 5/7] icmp: Use thread-based epoll management for ICMP flows Laurent Vivier
2025-10-20 1:35 ` David Gibson
2025-10-17 10:31 ` [PATCH v4 6/7] udp: Use thread-based epoll management for UDP flows Laurent Vivier
2025-10-20 1:39 ` David Gibson
2025-10-17 10:31 ` [PATCH v4 7/7] passt: Move main event loop processing into passt_worker() Laurent Vivier
2025-10-17 17:43 ` Stefano Brivio
2025-10-20 1:43 ` David Gibson
2025-10-21 8:00 ` Laurent Vivier [this message]
2025-10-22 0:53 ` David Gibson
2025-10-22 6:49 ` Laurent Vivier
2025-10-23 1:24 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=997ad29f-4c62-495b-b4bf-7405dbc55537@redhat.com \
--to=lvivier@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).