On Mon, Nov 10, 2025 at 03:40:25PM +1100, David Gibson wrote:
> On Fri, Nov 07, 2025 at 03:38:57PM +0100, Laurent Vivier wrote:
> > This series implements multiqueue support for vhost-user mode, allowing passt
> > to utilize multiple queue pairs. There is no improved network performance because
> > we keep using only one thread.
> > 
> > The implementation introduces a --max-queues parameter to configure up to 16
> > queue pairs (32 virtqueues) in vhost-user mode. Packets are routed to the
> > appropriate RX queue based on which TX queue they originated from, enabling the
> > guest kernel to distribute network traffic across multiple queues
> > and vCPUs.
> 
> I find this description a little bit confusing, since at the packet
> (L2) level things going to an Rx queue don't really have an
> originating Tx queue.  I assume you mean that each flow gets
> associated to a single queue pair, so both Rx and Tx packets on that
> flow will use the same queue pair (and, later, thread).  Is that
> correct?  If so I think it would be clearer to explicitly describe
> this in terms of flows.
> 
> > This series adds:
> > - configuration support for multiqueue via --max-queues parameter
> > - queue parameter threading throughout the network stack - a significant
> >   refactoring that propagates queue information through all protocol handlers
> >   (TCP, UDP, ICMP, ARP, DHCP, DHCPv6, NDP)
> > - flow-aware queue routing that matches RX queue selection to the incoming
> >   TX queue, maintaining proper packet affinity
> > - comprehensive test coverage with VHOST_USER_MQ environment variable to
> >   validate multiqueue functionality across all test scenarios
> > 
> > Current behavior: TX queue selection is controlled by the guest kernel, while
> > RX packets are routed to queues based on their associated flows. Host-initiated
> > flows currently default to queue 0.
> > 
> > The RX queue of a flow is updated on each new packet from the TX queue to
> > maintain affinity.
> > 
> > The changes maintain backward compatibility - without --max-queues, behavior
> > remains unchanged with single-queue operation.

Having now read the whole series.  I noted on an individual patch that
it's sometimes confusing what's being communicated as queue pair ID,
what as absolute queue ID.  Perhaps that discussion belongs better not
attached to a specific patch.

I think we should standardize on a single way of indexing, in as much
of the code as possible - the exception should be in the low-level
code that actually deals with the vq interfaces.  I _think_ queue pair
will simplify things compared to absolute queue number, but I might be
wrong.

-- 
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