From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Scr34u4o; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 7207C5A026D for ; Fri, 31 Jul 2026 18:16:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785514582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eTtgEBvYEiakWStwCXlGRgaVM41ifK4otvrUhL8qbLo=; b=Scr34u4o3sDE30onlLTNtysTCEhoiWF8jg6vGjACmvNh1t/HK+FbpLPMNiMcDeME3jmNyB Zs4lx9+/J0VWEosmIMEVLqTrrODwRYqFY1QMF0WUIiE5LnG4pvKIdzz5EPhwdd1xfMdwpP k8JvVCdzkJ15hzJk72KvJ5RK3OBlueI= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-381-z9l0dXEoOsiUVcSwADdX3A-1; Fri, 31 Jul 2026 12:16:20 -0400 X-MC-Unique: z9l0dXEoOsiUVcSwADdX3A-1 X-Mimecast-MFC-AGG-ID: z9l0dXEoOsiUVcSwADdX3A_1785514579 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 91CC7195608F for ; Fri, 31 Jul 2026 16:16:19 +0000 (UTC) Received: from lenovo-t14s.redhat.corp (headnet05.pony-001.prod.iad2.dc.redhat.com [10.2.32.117]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id C097C18004AD; Fri, 31 Jul 2026 16:16:18 +0000 (UTC) From: Laurent Vivier To: passt-dev@passt.top Subject: [PATCH v6 00/12] vhost-user: Add multiqueue support Date: Fri, 31 Jul 2026 18:16:05 +0200 Message-ID: <20260731161617.3550626-1-lvivier@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: VcXRnKEH3xrfnEbt0WhHV4Fn1ZkjX85NhNpNT7tcOLQ_1785514579 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID-Hash: IGRRWNHUTU3RP5FMLYEPB2NBFGA4O5EJ X-Message-ID-Hash: IGRRWNHUTU3RP5FMLYEPB2NBFGA4O5EJ X-MailFrom: lvivier@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Laurent Vivier X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This series implements multiqueue support for vhost-user mode, allowing passt to utilize multiple queue pairs for improved network throughput when used with multi-CPU guest VMs. While this version uses a single thread for packet processing, it enables the guest kernel to distribute network traffic across multiple queues and vCPUs. The implementation advertises support for up to 16 queue pairs (32 virtqueues) by setting VIRTIO_NET_F_MQ and VHOST_USER_PROTOCOL_F_MQ feature flags. Packets are routed to the appropriate RX queue based on which TX queue they originated from, following the virtio specification's automatic receive steering requirements. This series adds: - Multiqueue capability advertisement (VIRTIO_NET_F_MQ and VHOST_USER_PROTOCOL_F_MQ features) - Queue pair parameter throughout the network stack, propagated through all protocol handlers (TCP, UDP, ICMP, ARP, DHCP, DHCPv6, NDP) - Flow-aware queue routing that tracks the originating TX queue for each flow and routes return packets to the corresponding RX queue - Epoll fd derived directly from queue pair, removing the separate epollid field and simplifying flow-to-queue association - Test coverage with VHOST_USER_MQ environment variable to validate multiqueue functionality across all protocols (TCP, UDP, ICMP) and services (DHCP, NDP) Current behavior: - TX queue selection is controlled by the guest kernel's networking stack - RX packets are routed to queues based on their associated flows, with the queue assignment updated on each packet from TX to maintain affinity - Host-initiated flows (e.g., from socket-side connections) currently default to queue pair 0 The changes are transparent to single-queue operation - passt/pasta modes and single-queue vhost-user configurations continue to work unchanged, always using queue pair 0. v6: - Rebase on latest master - Moved flow_migrate()/FLOW_MIGRATE() to a following series - this series now focuses solely on basic multiqueue support without dynamic flow migration between queue pairs. - qpair is now a parameter of flow_alloc(). - Made flow_setqp() static (only called during flow allocation) - Updated for upstream changes to flow logging infrastructure (flow_log__(), new logging macros with improved perror and details handling) - Updated for upstream migration handler signature changes (added 'now' parameter to flow_migrate_source_pre(), flow_migrate_source(), and flow_migrate_target()) v5: - Rebase - Dropped "tap: Convert packet pools to per-queue-pair arrays for multiqueue" - Split "vhost-user: Add queue pair parameter throughout the network stack" into separate per-protocol patches (tap, arp, tcp, udp, dhcp/dhcpv6, icmp, ndp) for easier review - New patch: "flow: Derive epoll fd from queue pair, removing epollid field" derives epoll fd directly from queue pair, removing the redundant epollid field and adding flow_migrate()/FLOW_MIGRATE() for existing flows - tcp_keepalive() and tcp_inactivity() now filter flows by queue pair - Renamed "vhost-user: Enable multiqueue" to "vhost-user: Advertise multiqueue support" v4: - Rebase - Added QPAIR_DEFAULT, QPAIR_FROMGUEST_QUEUE(), QPAIR_TOGUEST_QUEUE(), and QPAIR_FROM_QUEUE() macros to centralize queue pair calculations - Replaced hardcoded 0 with QPAIR_DEFAULT throughout for clarity - Set queue pair at flow creation time in icmp_ping_new() and udp_flow_new() rather than after creation - Removed vhost-user-specific queue macros (VHOST_USER_TX_QUEUE, VHOST_USER_IS_QUEUE_TX, VHOST_USER_IS_QUEUE_RX) in favor of generic QPAIR_* macros for better consistency v3: - Removed --max-qpairs configuration option - multiqueue support is now always enabled up to 16 queue pairs without requiring explicit configuration - Replaced "tap: Add queue pair parameter throughout the packet processing path" with "tap: Convert packet pools to per-queue-pair arrays for multiqueue" - simplified implementation by converting global pools to arrays rather than passing pool parameters throughout - Changed qpair parameter type from int to unsigned int throughout the codebase - Simplified test infrastructure - queues parameter is always set on netdev, mq=true added to virtio-net only when VHOST_USER_MQ > 1 - Updated QEMU usage hints to always show multiqueue-capable command line v2: - New patch: "tap: Remove pool parameter from tap4_handler() and tap6_handler()" to clean up unused parameters before adding queue pair parameter - Changed to one packet pool per queue pair instead of shared pools across all queue pairs - Split "multiqueue: Add queue-aware flow management..." into two patches: - "tap: Add queue pair parameter throughout the packet processing path" - "flow: Add queue pair tracking to flow management" - Updated test infrastructure patch with refined implementation Laurent Vivier (12): tap: Remove pool parameter from tap4_handler() and tap6_handler() vhost-user: Advertise multiqueue support test: Add multiqueue support to vhost-user test infrastructure tap: Thread queue pair through all remaining tap paths arp: Pass queue pair explicitly through ARP send path tcp: Pass queue pair explicitly through TCP send path udp: Pass queue pair explicitly through UDP send path dhcp/dhcpv6: Pass queue pair explicitly through DHCP send path icmp: Pass queue pair explicitly through ICMP send path ndp: Pass queue pair explicitly through NDP send path flow: Add queue pair tracking to flow management flow: Derive epoll fd from queue pair, removing epollid field arp.c | 9 ++- arp.h | 2 +- dhcp.c | 5 +- dhcp.h | 2 +- dhcpv6.c | 13 +-- dhcpv6.h | 2 +- flow.c | 45 +++++------ flow.h | 20 ++--- flow_table.h | 2 +- icmp.c | 24 +++--- icmp.h | 7 +- ndp.c | 33 ++++---- ndp.h | 2 +- passt.c | 25 +++--- passt.h | 10 +++ tap.c | 118 ++++++++++++++------------- tap.h | 19 ++--- tcp.c | 211 ++++++++++++++++++++++++++++--------------------- tcp.h | 15 ++-- tcp_buf.c | 8 +- tcp_internal.h | 6 +- tcp_splice.c | 1 - tcp_vu.c | 19 +++-- tcp_vu.h | 5 +- test/lib/setup | 21 +++-- test/run | 23 ++++++ udp.c | 48 ++++++----- udp.h | 9 ++- udp_flow.c | 27 ++++--- udp_flow.h | 13 +-- udp_internal.h | 3 +- udp_vu.c | 7 +- udp_vu.h | 3 +- vhost_user.c | 12 +-- vhost_user.h | 9 --- virtio.h | 2 +- vu_common.c | 22 +++--- vu_common.h | 3 +- 38 files changed, 462 insertions(+), 343 deletions(-) -- 2.54.0