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