Subject: Re: [PATCH 5/5] selftests: net: add rss_multiqueue test variant to iou-zcrx

From: Juanlu Herrero <[email-masked]>
Date: Mon, 13 Apr 2026 11:01:59 -0500

On Fri, Apr 10, 2026 at 03:26:54PM -0600, David Wei wrote:
> On 2026-04-08 09:38, Juanlu Herrero wrote:
> > Add multi-port support to the iou-zcrx test binary and a new
> > rss_multiqueue Python test variant that exercises multi-queue zero-copy
> > receive with per-port flow rule steering.
> > 
> > In multi-port mode, the server creates N listening sockets on
> > consecutive ports (cfg_port, cfg_port+1, ...) and uses epoll to accept
> > one connection per socket. Each client thread connects to its
> > corresponding port. Per-port ntuple flow rules steer traffic to
> > different NIC hardware queues, each with its own zcrx instance.
> > 
> > For single-thread mode (the default), behavior is unchanged: one socket
> > on cfg_port, one thread, one queue.
> > 
> > Signed-off-by: Juanlu Herrero <[email-masked]>
> > ---
> >   .../selftests/drivers/net/hw/iou-zcrx.c       | 81 ++++++++++++++-----
> >   .../selftests/drivers/net/hw/iou-zcrx.py      | 45 ++++++++++-
> >   2 files changed, 104 insertions(+), 22 deletions(-)
> > 
> > diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > index 646682167bb0..1f33d7127185 100644
> > --- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> > +++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> 
> Please make all changes in iou-zcrx.c in a single patch. Then patch 5
> only changes the Python selftest.
> 
> [...]
> > @@ -397,12 +410,36 @@ static void run_server(void)
> >   	if (cfg_dry_run)
> >   		goto join;
> > +	epfd = epoll_create1(0);
> > +	if (epfd < 0)
> > +		error(1, 0, "epoll_create1()");
> > +
> >   	for (i = 0; i < cfg_num_threads; i++) {
> > -		ctxs[i].connfd = accept(fd, NULL, NULL);
> > -		if (ctxs[i].connfd < 0)
> > -			error(1, 0, "accept()");
> > +		ev.events = EPOLLIN;
> > +		ev.data.u32 = i;
> > +		if (epoll_ctl(epfd, EPOLL_CTL_ADD, fds[i], &ev) < 0)
> > +			error(1, 0, "epoll_ctl()");
> >   	}
> > +	accepted = 0;
> > +	while (accepted < cfg_num_threads) {
> 
> You're using epoll here but it is still accepting a fixed nr of
> connections. The server should be able to accept an arbitrary nr of
> connections, dispatching them to the server worker threads.
> 
> Also with multiple queues, connections must be dispatched according to
> their NAPI IDs to the correct server workers.
> 
> > +		nfds = epoll_wait(epfd, events, 64, 5000);
> > +		if (nfds < 0)
> > +			error(1, 0, "epoll_wait()");
> > +		if (nfds == 0)
> > +			error(1, 0, "epoll_wait() timeout");
> > +
> > +		for (i = 0; i < nfds; i++) {
> > +			int idx = events[i].data.u32;
> > +
> > +			ctxs[idx].connfd = accept(fds[idx], NULL, NULL);
> > +			if (ctxs[idx].connfd < 0)
> > +				error(1, 0, "accept()");
> > +			accepted++;
> > +		}
> > +	}
> > +
> > +	close(epfd);
> >   	pthread_barrier_wait(&barrier);
> >   join:

Makes sense, I will re-work the patches and address the epoll & NAPI
id feedback. Thanks!