On 11/26/25 03:20, David Gibson wrote:
On Fri, Nov 21, 2025 at 05:58:58PM +0100, Laurent Vivier wrote:
Add the --max-queues parameter to specify the maximum number of queue
Nit: you updated the option to be --max-qpairs, which I think is good, but now the commit message is out of date.
One other query: what makes it "max qpairs" rather than just "qpairs" - are there (now or in planned work) circumstances where you'd end up with less qpairs than specified here?
In fact, the number of qpairs is negociated by the guest. If you start passt with max-qpairs=16 but QEMU with queues=4, it will only use 4 qpairs. If you start QEMU with queues=17, it will fail. Perhaps we can remove the parameter and rely only on the hardcoded one (32 virtqueues = 16 qpairs)? I can add "--mq" parameter instead to enable multiqueue?
pairs supported in vhost-user mode. This enables multi-queue support by allowing configuration of up to 16 queue pairs (32 virtqueues).
For the moment, only the first RX queue is used, the TX queue is selected by the guest kernel.
IIUC, with this patch (but not the ones after) things will break if the guest uses a qpair other than 0, right? AFAICT vu_kick_cb() isn't updated so will ignore anything on the other qpairs.
No, I think it should work. For the TX part (from guest) we add all the kick_fd to the epollfd, so all the TX queues are managed. But we we use only RX queue 0, that is not what is expected by the guest kernel as we should use the same queue pair but I think kernel will process them anyway. Thanks, Laurent