- dev - passt

[RFC 00/12] Support for multiple address and late binding
by Jon Maloy 18 Dec '25

18 Dec '25

This series add functionality corresponding to three user stories in https://pad.passt.top/p/NetlinkMonitor: US-1: Dynamic Network Configuration Updates (PASTA) US-3: US-3: Multiple IPv6 Addresses (PASTA) US-4: Multiple IPv4 Addresses (PASTA) Jon Maloy (12): ip: Introduce multi-address data structures for IPv4 and IPv6 ip: Add ip4_default_prefix_len() helper function for class-based prefix conf: Allow multiple -a/--address options per address family conf: Apply -n/--netmask to most recently added address fwd: Check all configured addresses in guest accessibility functions arp: Check all configured addresses in ARP filtering netlink: Subscribe to link/address changes in namespace netlink: Subscribe to route changes in namespace netlink: Add host-side monitoring for late template interface binding netlink: Add host-side route monitoring and propagation netlink: Prevent host route events from overwriting guest-configured gateway netlink: Rename tap interface when late binding discovers template name arp.c | 11 +- conf.c | 135 +++++--- dhcp.c | 8 +- dhcpv6.c | 6 +- epoll_type.h | 4 + fwd.c | 30 +- ip.c | 21 ++ ip.h | 28 ++ isolation.c | 4 + ndp.c | 6 +- netlink.c | 869 +++++++++++++++++++++++++++++++++++++++++++++++++++ netlink.h | 6 + passt.c | 9 + passt.h | 21 +- pasta.c | 28 +- tap.c | 37 ++- tap.h | 1 + util.h | 1 + 18 files changed, 1137 insertions(+), 88 deletions(-) -- 2.51.1

2 31

[PATCH v2] conf: Support CIDR notation for -a/--address option
by Jon Maloy 18 Dec '25

18 Dec '25

Extend the -a/--address option to accept addresses in CIDR notation (e.g., 192.168.1.1/24 or 2001:db8::1/64) as an alternative to using separate -a and -n options. Add conf_addr_prefix() helper function that: - Parses address strings with optional /prefix suffix - Validates prefix length based on address family (0-32 for IPv4, 0-128 for IPv6) - Returns address family and fills address/prefix output parameters For IPv4, the prefix is stored in ip4.prefix_len when provided. Multiple CIDR addresses use last-wins semantics for the prefix, consistent with how addresses are handled currently. However, mixing -n and CIDR notation results in an error to catch likely user mistakes. Also fix a bug in conf_ip4_prefix() that was incorrectly using the global 'optarg' instead of its 'arg' parameter. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- v2: Fixed incorrect error printout, as noted by Laurent Vivier. We now keep the old semantics, i.e., allowing multiple -a options for each protocol. This semantics looks wrong, but will anyway be fixed in my upcoming series. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- conf.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 84 insertions(+), 15 deletions(-) diff --git a/conf.c b/conf.c index 2942c8c..764b910 100644 --- a/conf.c +++ b/conf.c @@ -682,7 +682,7 @@ static int conf_ip4_prefix(const char *arg) return -1; } else { errno = 0; - len = strtoul(optarg, NULL, 0); + len = strtoul(arg, NULL, 0); if (len > 32 || errno) return -1; } @@ -690,6 +690,56 @@ static int conf_ip4_prefix(const char *arg) return len; } +/** + * conf_addr_prefix() - Parse address with optional /prefix notation + * @arg: Address string, optionally with /prefix + * @addr4: Output for IPv4 address + * @addr6: Output for IPv6 address + * @prefix: Output for prefix length (0 if not specified) + * + * Return: AF_INET for IPv4, AF_INET6 for IPv6, -1 on error + */ +static int conf_addr_prefix(const char *arg, struct in_addr *addr4, + struct in6_addr *addr6, int *prefix) +{ + char buf[INET6_ADDRSTRLEN + sizeof("/128")]; + char *slash; + + *prefix = 0; + + if (snprintf(buf, sizeof(buf), "%s", arg) >= (int)sizeof(buf)) + return -1; + + /* Check for /prefix suffix */ + slash = strchr(buf, '/'); + if (slash) { + unsigned long len; + char *end; + + *slash = '\0'; + errno = 0; + len = strtoul(slash + 1, &end, 10); + if (errno || *end) + return -1; + + *prefix = len; + } + + if (inet_pton(AF_INET6, buf, addr6) == 1) { + if (*prefix > 128) + return -1; + return AF_INET6; + } + + if (inet_pton(AF_INET, buf, addr4) == 1) { + if (*prefix > 32) + return -1; + return AF_INET; + } + + return -1; +} + /** * conf_ip4() - Verify or detect IPv4 support, get relevant addresses * @ifi: Host interface to attempt (0 to determine one) @@ -896,7 +946,7 @@ static void usage(const char *name, FILE *f, int status) " a zero value disables assignment\n" " default: 65520: maximum 802.3 MTU minus 802.3 header\n" " length, rounded to 32 bits (IPv4 words)\n" - " -a, --address ADDR Assign IPv4 or IPv6 address ADDR\n" + " -a, --address ADDR Assign IPv4 or IPv6 address ADDR[/PREFIX]\n" " can be specified zero to two times (for IPv4 and IPv6)\n" " default: use addresses from interface with default route\n" " -n, --netmask MASK Assign IPv4 MASK, dot-decimal or bits\n" @@ -1499,6 +1549,7 @@ void conf(struct ctx *c, int argc, char **argv) const char *logname = (c->mode == MODE_PASTA) ? "pasta" : "passt"; char userns[PATH_MAX] = { 0 }, netns[PATH_MAX] = { 0 }; bool copy_addrs_opt = false, copy_routes_opt = false; + bool prefix_from_cidr = false, prefix_from_opt = false; enum fwd_ports_mode fwd_default = FWD_NONE; bool v4_only = false, v6_only = false; unsigned dns4_idx = 0, dns6_idx = 0; @@ -1808,23 +1859,38 @@ void conf(struct ctx *c, int argc, char **argv) c->mtu = mtu; break; } - case 'a': - if (inet_pton(AF_INET6, optarg, &c->ip6.addr) && - !IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr) && - !IN6_IS_ADDR_LOOPBACK(&c->ip6.addr) && - !IN6_IS_ADDR_V4MAPPED(&c->ip6.addr) && - !IN6_IS_ADDR_V4COMPAT(&c->ip6.addr) && - !IN6_IS_ADDR_MULTICAST(&c->ip6.addr)) { + case 'a': { + struct in6_addr addr6; + struct in_addr addr4; + int prefix = 0; + int af; + + af = conf_addr_prefix(optarg, &addr4, &addr6, &prefix); + + if (af == AF_INET6 && + !IN6_IS_ADDR_UNSPECIFIED(&addr6) && + !IN6_IS_ADDR_LOOPBACK(&addr6) && + !IN6_IS_ADDR_V4MAPPED(&addr6) && + !IN6_IS_ADDR_V4COMPAT(&addr6) && + !IN6_IS_ADDR_MULTICAST(&addr6)) { + c->ip6.addr = addr6; if (c->mode == MODE_PASTA) c->ip6.no_copy_addrs = true; break; } - if (inet_pton(AF_INET, optarg, &c->ip4.addr) && - !IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr) && - !IN4_IS_ADDR_BROADCAST(&c->ip4.addr) && - !IN4_IS_ADDR_LOOPBACK(&c->ip4.addr) && - !IN4_IS_ADDR_MULTICAST(&c->ip4.addr)) { + if (af == AF_INET && + !IN4_IS_ADDR_UNSPECIFIED(&addr4) && + !IN4_IS_ADDR_BROADCAST(&addr4) && + !IN4_IS_ADDR_LOOPBACK(&addr4) && + !IN4_IS_ADDR_MULTICAST(&addr4)) { + c->ip4.addr = addr4; + if (prefix) { + if (prefix_from_opt) + die("Can't use both -n and CIDR prefix"); + c->ip4.prefix_len = prefix; + prefix_from_cidr = true; + } if (c->mode == MODE_PASTA) c->ip4.no_copy_addrs = true; break; @@ -1832,11 +1898,14 @@ void conf(struct ctx *c, int argc, char **argv) die("Invalid address: %s", optarg); break; + } case 'n': + if (prefix_from_cidr) + die("Can't use both -n and CIDR prefix"); c->ip4.prefix_len = conf_ip4_prefix(optarg); if (c->ip4.prefix_len < 0) die("Invalid netmask: %s", optarg); - + prefix_from_opt = true; break; case 'M': parse_mac(c->our_tap_mac, optarg); -- 2.52.0

3 2

[PATCH] conf: Support CIDR notation for -a/--address option
by Jon Maloy 17 Dec '25

17 Dec '25

We extend the -a/--address option to accept addresses in CIDR notation (e.g., 192.168.1.1/24 or 2001:db8::1/64) as an alternative to using separate -a and -n options. For IPv4, the prefix is stored in ip4.prefix_len when provided. The CIDR prefix and -n/--netmask options are mutually exclusive - using both results in an error. Also fix a bug in conf_ip4_prefix() that was incorrectly using the global 'optarg' instead of its 'arg' parameter. Signed-off-by: Jon Maloy <jmaloy(a)redhat.com> --- conf.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 84 insertions(+), 15 deletions(-) diff --git a/conf.c b/conf.c index 2942c8c..0f66c77 100644 --- a/conf.c +++ b/conf.c @@ -682,7 +682,7 @@ static int conf_ip4_prefix(const char *arg) return -1; } else { errno = 0; - len = strtoul(optarg, NULL, 0); + len = strtoul(arg, NULL, 0); if (len > 32 || errno) return -1; } @@ -690,6 +690,56 @@ static int conf_ip4_prefix(const char *arg) return len; } +/** + * conf_addr_prefix() - Parse address with optional /prefix notation + * @arg: Address string, optionally with /prefix + * @addr4: Output for IPv4 address + * @addr6: Output for IPv6 address + * @prefix: Output for prefix length (0 if not specified) + * + * Return: AF_INET for IPv4, AF_INET6 for IPv6, -1 on error + */ +static int conf_addr_prefix(const char *arg, struct in_addr *addr4, + struct in6_addr *addr6, int *prefix) +{ + char buf[INET6_ADDRSTRLEN + sizeof("/128")]; + char *slash; + + *prefix = 0; + + if (snprintf(buf, sizeof(buf), "%s", arg) >= (int)sizeof(buf)) + return -1; + + /* Check for /prefix suffix */ + slash = strchr(buf, '/'); + if (slash) { + unsigned long len; + char *end; + + *slash = '\0'; + errno = 0; + len = strtoul(slash + 1, &end, 10); + if (errno || *end) + return -1; + + *prefix = len; + } + + if (inet_pton(AF_INET6, buf, addr6) == 1) { + if (*prefix > 128) + return -1; + return AF_INET6; + } + + if (inet_pton(AF_INET, buf, addr4) == 1) { + if (*prefix > 32) + return -1; + return AF_INET; + } + + return -1; +} + /** * conf_ip4() - Verify or detect IPv4 support, get relevant addresses * @ifi: Host interface to attempt (0 to determine one) @@ -896,7 +946,7 @@ static void usage(const char *name, FILE *f, int status) " a zero value disables assignment\n" " default: 65520: maximum 802.3 MTU minus 802.3 header\n" " length, rounded to 32 bits (IPv4 words)\n" - " -a, --address ADDR Assign IPv4 or IPv6 address ADDR\n" + " -a, --address ADDR Assign IPv4 or IPv6 address ADDR[/PREFIX]\n" " can be specified zero to two times (for IPv4 and IPv6)\n" " default: use addresses from interface with default route\n" " -n, --netmask MASK Assign IPv4 MASK, dot-decimal or bits\n" @@ -1501,6 +1551,7 @@ void conf(struct ctx *c, int argc, char **argv) bool copy_addrs_opt = false, copy_routes_opt = false; enum fwd_ports_mode fwd_default = FWD_NONE; bool v4_only = false, v6_only = false; + bool prefix_explicit = false; unsigned dns4_idx = 0, dns6_idx = 0; unsigned long max_mtu = IP_MAX_MTU; struct fqdn *dnss = c->dns_search; @@ -1808,23 +1859,38 @@ void conf(struct ctx *c, int argc, char **argv) c->mtu = mtu; break; } - case 'a': - if (inet_pton(AF_INET6, optarg, &c->ip6.addr) && - !IN6_IS_ADDR_UNSPECIFIED(&c->ip6.addr) && - !IN6_IS_ADDR_LOOPBACK(&c->ip6.addr) && - !IN6_IS_ADDR_V4MAPPED(&c->ip6.addr) && - !IN6_IS_ADDR_V4COMPAT(&c->ip6.addr) && - !IN6_IS_ADDR_MULTICAST(&c->ip6.addr)) { + case 'a': { + struct in6_addr addr6; + struct in_addr addr4; + int prefix = 0; + int af; + + af = conf_addr_prefix(optarg, &addr4, &addr6, &prefix); + + if (af == AF_INET6 && + !IN6_IS_ADDR_UNSPECIFIED(&addr6) && + !IN6_IS_ADDR_LOOPBACK(&addr6) && + !IN6_IS_ADDR_V4MAPPED(&addr6) && + !IN6_IS_ADDR_V4COMPAT(&addr6) && + !IN6_IS_ADDR_MULTICAST(&addr6)) { + c->ip6.addr = addr6; if (c->mode == MODE_PASTA) c->ip6.no_copy_addrs = true; break; } - if (inet_pton(AF_INET, optarg, &c->ip4.addr) && - !IN4_IS_ADDR_UNSPECIFIED(&c->ip4.addr) && - !IN4_IS_ADDR_BROADCAST(&c->ip4.addr) && - !IN4_IS_ADDR_LOOPBACK(&c->ip4.addr) && - !IN4_IS_ADDR_MULTICAST(&c->ip4.addr)) { + if (af == AF_INET && + !IN4_IS_ADDR_UNSPECIFIED(&addr4) && + !IN4_IS_ADDR_BROADCAST(&addr4) && + !IN4_IS_ADDR_LOOPBACK(&addr4) && + !IN4_IS_ADDR_MULTICAST(&addr4)) { + c->ip4.addr = addr4; + if (prefix) { + if (prefix_explicit) + die("Can't use both -n and CIDR prefix"); + c->ip4.prefix_len = prefix; + prefix_explicit = true; + } if (c->mode == MODE_PASTA) c->ip4.no_copy_addrs = true; break; @@ -1832,11 +1898,14 @@ void conf(struct ctx *c, int argc, char **argv) die("Invalid address: %s", optarg); break; + } case 'n': + if (prefix_explicit) + die("Can't use both -n and CIDR prefix"); c->ip4.prefix_len = conf_ip4_prefix(optarg); if (c->ip4.prefix_len < 0) die("Invalid netmask: %s", optarg); - + prefix_explicit = true; break; case 'M': parse_mac(c->our_tap_mac, optarg); -- 2.52.0

2 1

passt: new version 2025_12_15.b40f5cd available
by Stefano Brivio 15 Dec '25

15 Dec '25

The new version with tag 2025_12_15.b40f5cd includes the following changes: b40f5cd tcp: Use less-than-MSS window on no queued data, or no data sent recently 35fa86a conf, fwd: Move initialisation of auto port scanning out of conf() 5be1a22 tcp: Remove extra space from TCP_INFO debug messages (trivial) 87f1a91 pasta: Clean up waiting pasta child on failures e6612fe treewide: Introduce passt_exit() helper d6c5b6e tcp: Suppress new instance of cppcheck bug 14191 https://passt.top/passt/log/?qt=range&q=2025_12_10.d04c480..2025_12_15.b40f… Packages: - Alpine Linux: https://pkgs.alpinelinux.org/packages?name=passt - Arch Linux: https://www.archlinux.org/packages/extra/x86_64/passt/ https://archlinuxarm.org/packages/aarch64/passt https://archlinuxarm.org/packages/armv7h/passt - Chimera: https://pkgs.chimera-linux.org/packages?name=passt - Clear Linux: https://github.com/clearlinux-pkgs/passt/ - Copr (CentOS Stream, EPEL, Fedora, Mageia): https://copr.fedorainfracloud.org/coprs/sbrivio/passt/build/9911424/ permanent mirror: https://passt.top/builds/copr/0^20251215.gb40f5cd/ - Debian tracker: https://tracker.debian.org/pkg/passt - Fedora updates: https://bodhi.fedoraproject.org/updates/?packages=passt - Gentoo versions: https://packages.gentoo.org/packages/net-misc/passt - GNU Guix: https://packages.guix.gnu.org/packages/passt/ - Homebrew: https://formulae.brew.sh/formula/passt - NixOS: https://github.com/NixOS/nixpkgs/tree/nixos-unstable/pkgs/by-name/pa/passt - openSUSE: https://software.opensuse.org/package/passt - OpenMandriva: https://github.com/OpenMandrivaAssociation/passt/tree/master - PLD Linux: https://git.pld-linux.org/cgi-bin/gitweb.cgi?p=packages/passt.git - Solus: https://github.com/getsolus/packages/tree/main/packages/p/passt - Ubuntu tracker: https://launchpad.net/ubuntu/+source/passt - Void Linux: https://voidlinux.org/packages/?q=passt - Static builds: - Package for other RPM-based distributions, x86_64 only: https://passt.top/builds/latest/x86_64/passt-gb40f5cd-1.x86_64.rpm - x86_64 static binaries: https://passt.top/builds/latest/x86_64/ - Debian package, from x86_64 static build: https://passt.top/builds/latest/x86_64/passt_0b40f5cd-1_all.deb -- Stefano

1 0

[PATCH v4 0/6] vhost-user: Add multiqueue support
by Laurent Vivier 15 Dec '25

15 Dec '25

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) - Per-queue-pair packet pools to support concurrent queue operations - 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 - 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. 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 (6): tap: Remove pool parameter from tap4_handler() and tap6_handler() vhost-user: Enable multiqueue test: Add multiqueue support to vhost-user test infrastructure vhost-user: Add queue pair parameter throughout the network stack tap: Convert packet pools to per-queue-pair arrays for multiqueue flow: Add queue pair tracking to flow management arp.c | 15 +++-- arp.h | 6 +- dhcp.c | 5 +- dhcp.h | 2 +- dhcpv6.c | 12 ++-- dhcpv6.h | 2 +- flow.c | 33 +++++++++ flow.h | 17 +++++ fwd.c | 18 ++--- fwd.h | 5 +- icmp.c | 33 +++++---- icmp.h | 4 +- ndp.c | 35 ++++++---- ndp.h | 7 +- netlink.c | 2 +- passt.c | 2 +- passt.h | 8 +++ tap.c | 180 ++++++++++++++++++++++++++++--------------------- tap.h | 22 +++--- tcp.c | 47 +++++++------ tcp.h | 7 +- tcp_vu.c | 8 ++- test/lib/setup | 21 +++--- test/run | 23 +++++++ udp.c | 47 +++++++------ udp.h | 6 +- udp_flow.c | 15 +++-- udp_flow.h | 2 +- udp_internal.h | 4 +- udp_vu.c | 4 +- vhost_user.c | 14 ++-- vhost_user.h | 6 -- virtio.h | 2 +- vu_common.c | 24 ++++--- vu_common.h | 3 +- 35 files changed, 403 insertions(+), 238 deletions(-) -- 2.51.1

1 6

[PATCH] udp: Rename udp_buf_sock_to_tap() and udp_vu_sock_to_tap()
by Laurent Vivier 15 Dec '25

15 Dec '25

The function udp_vu_sock_to_tap() sends data to the vhost-user interface, not the tap interface. Rename it to udp_sock_to_vu() to accurately reflect its destination. The function udp_buf_sock_to_tap() includes a "buf_" prefix that is now redundant. Since the functions can be distinguished by their destination (to_tap vs. to_vu), drop the prefix and rename it to udp_sock_to_tap(). No functional change. Signed-off-by: Laurent Vivier <lvivier(a)redhat.com> --- udp.c | 15 +++++++-------- udp_vu.c | 4 ++-- udp_vu.h | 2 +- 3 files changed, 10 insertions(+), 11 deletions(-) diff --git a/udp.c b/udp.c index 08bec50a27af..10704681973b 100644 --- a/udp.c +++ b/udp.c @@ -824,14 +824,14 @@ static void udp_sock_to_sock(const struct ctx *c, int from_s, int n, } /** - * udp_buf_sock_to_tap() - Forward datagrams from socket to tap + * udp_sock_to_tap() - Forward datagrams from socket to tap * @c: Execution context * @s: Socket to read data from * @n: Maximum number of datagrams to forward * @tosidx: Flow & side to forward data from @s to */ -static void udp_buf_sock_to_tap(const struct ctx *c, int s, int n, - flow_sidx_t tosidx) +static void udp_sock_to_tap(const struct ctx *c, int s, int n, + flow_sidx_t tosidx) { const struct flowside *toside = flowside_at_sidx(tosidx); struct udp_flow *uflow = udp_at_sidx(tosidx); @@ -892,9 +892,9 @@ void udp_sock_fwd(const struct ctx *c, int s, uint8_t frompif, udp_sock_to_sock(c, s, 1, tosidx); } else if (topif == PIF_TAP) { if (c->mode == MODE_VU) - udp_vu_sock_to_tap(c, s, 1, tosidx); + udp_sock_to_vu(c, s, 1, tosidx); else - udp_buf_sock_to_tap(c, s, 1, tosidx); + udp_sock_to_tap(c, s, 1, tosidx); } else if (flow_sidx_valid(tosidx)) { struct udp_flow *uflow = udp_at_sidx(tosidx); @@ -972,10 +972,9 @@ void udp_sock_handler(const struct ctx *c, union epoll_ref ref, udp_sock_to_sock(c, ref.fd, n, tosidx); } else if (topif == PIF_TAP) { if (c->mode == MODE_VU) { - udp_vu_sock_to_tap(c, s, UDP_MAX_FRAMES, - tosidx); + udp_sock_to_vu(c, s, UDP_MAX_FRAMES, tosidx); } else { - udp_buf_sock_to_tap(c, s, n, tosidx); + udp_sock_to_tap(c, s, n, tosidx); } } else { flow_err(uflow, diff --git a/udp_vu.c b/udp_vu.c index c30dcf97698f..f7ed6bc6a67c 100644 --- a/udp_vu.c +++ b/udp_vu.c @@ -197,13 +197,13 @@ static void udp_vu_csum(const struct flowside *toside, int iov_used) } /** - * udp_vu_sock_to_tap() - Forward datagrams from socket to tap + * udp_sock_to_vu() - Forward datagrams from socket to vhost-user * @c: Execution context * @s: Socket to read data from * @n: Maximum number of datagrams to forward * @tosidx: Flow & side to forward data from @s to */ -void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) +void udp_sock_to_vu(const struct ctx *c, int s, int n, flow_sidx_t tosidx) { const struct flowside *toside = flowside_at_sidx(tosidx); bool v6 = !(inany_v4(&toside->eaddr) && inany_v4(&toside->oaddr)); diff --git a/udp_vu.h b/udp_vu.h index 576b0e716f3d..669bde1c10dc 100644 --- a/udp_vu.h +++ b/udp_vu.h @@ -8,6 +8,6 @@ void udp_vu_listen_sock_data(const struct ctx *c, union epoll_ref ref, const struct timespec *now); -void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx); +void udp_sock_to_vu(const struct ctx *c, int s, int n, flow_sidx_t tosidx); #endif /* UDP_VU_H */ -- 2.51.1

3 3

[PATCH v2 0/9] tcp: Fix throughput issues with non-local peers
by Stefano Brivio 15 Dec '25

15 Dec '25

Patch 2/9 is the most relevant fix here, as we currently advertise a window that might be too big for what we can write to the socket, causing retransmissions right away and occasional high latency on short transfers to non-local peers. Mostly as a consequence of fixing that, we now need several improvements and small fixes, including, most notably, an adaptive approach to pick the interval between checks for socket-side ACKs (patch 3/9), and several tricks to reliably trigger TCP buffer size auto-tuning as implemented by the Linux kernel (patches 5/9 and 7/9). These changes make some existing issues more relevant, fixed by the other patches. With this series, I'm getting the expected (wirespeed) throughput for transfers between peers with varying non-local RTTs: I checked different guests bridged on the same machine (~500 us) and hosts with increasing distance using iperf3, as well as HTTP transfers only for some hosts I have control over (500 us and 5 ms case). With increasing RTTs, I can finally see the throughput converging to the available bandwidth reasonably fast: * 500 us RTT, ~10 Gbps available: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 785 MBytes 6.57 Gbits/sec 13 1.84 MBytes [ 5] 1.00-2.00 sec 790 MBytes 6.64 Gbits/sec 0 1.92 MBytes * 5 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 4.88 MBytes 40.9 Mbits/sec 22 240 KBytes [ 5] 1.00-2.00 sec 46.2 MBytes 388 Mbits/sec 34 900 KBytes [ 5] 2.00-3.00 sec 110 MBytes 923 Mbits/sec 0 1.11 MBytes * 10 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 67.9 MBytes 569 Mbits/sec 2 960 KBytes [ 5] 1.00-2.00 sec 110 MBytes 926 Mbits/sec 0 1.05 MBytes [ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec 0 1.17 MBytes * 24 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.50 MBytes 20.9 Mbits/sec 16 240 KBytes [ 5] 1.00-2.00 sec 1.50 MBytes 12.6 Mbits/sec 9 120 KBytes [ 5] 2.00-3.00 sec 99.2 MBytes 832 Mbits/sec 4 2.40 MBytes [ 5] 3.00-4.00 sec 122 MBytes 1.03 Gbits/sec 1 3.16 MBytes [ 5] 4.00-5.00 sec 119 MBytes 1.00 Gbits/sec 0 4.16 MBytes * 40 ms, ~600 Mbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.12 MBytes 17.8 Mbits/sec 0 600 KBytes [ 5] 1.00-2.00 sec 3.25 MBytes 27.3 Mbits/sec 14 420 KBytes [ 5] 2.00-3.00 sec 31.5 MBytes 264 Mbits/sec 11 1.29 MBytes [ 5] 3.00-4.00 sec 72.5 MBytes 608 Mbits/sec 0 1.46 MBytes * 100 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 4.88 MBytes 40.9 Mbits/sec 1 840 KBytes [ 5] 1.00-2.00 sec 1.62 MBytes 13.6 Mbits/sec 9 240 KBytes [ 5] 2.00-3.00 sec 5.25 MBytes 44.0 Mbits/sec 5 780 KBytes [ 5] 3.00-4.00 sec 9.75 MBytes 81.8 Mbits/sec 0 1.29 MBytes [ 5] 4.00-5.00 sec 15.8 MBytes 132 Mbits/sec 0 1.99 MBytes [ 5] 5.00-6.00 sec 22.9 MBytes 192 Mbits/sec 0 3.05 MBytes [ 5] 6.00-7.00 sec 132 MBytes 1.11 Gbits/sec 0 7.62 MBytes * 114 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.62 MBytes 13.6 Mbits/sec 8 420 KBytes [ 5] 1.00-2.00 sec 2.12 MBytes 17.8 Mbits/sec 15 120 KBytes [ 5] 2.00-3.00 sec 26.0 MBytes 218 Mbits/sec 50 1.82 MBytes [ 5] 3.00-4.00 sec 103 MBytes 865 Mbits/sec 31 5.10 MBytes [ 5] 4.00-5.00 sec 111 MBytes 930 Mbits/sec 0 5.92 MBytes * 153 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.12 MBytes 9.43 Mbits/sec 2 180 KBytes [ 5] 1.00-2.00 sec 2.12 MBytes 17.8 Mbits/sec 11 180 KBytes [ 5] 2.00-3.00 sec 12.6 MBytes 106 Mbits/sec 40 1.29 MBytes [ 5] 3.00-4.00 sec 44.5 MBytes 373 Mbits/sec 22 2.75 MBytes [ 5] 4.00-5.00 sec 86.0 MBytes 721 Mbits/sec 0 6.68 MBytes [ 5] 5.00-6.00 sec 120 MBytes 1.01 Gbits/sec 119 6.97 MBytes [ 5] 6.00-7.00 sec 110 MBytes 927 Mbits/sec 0 6.97 MBytes * 186 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.12 MBytes 9.43 Mbits/sec 3 180 KBytes [ 5] 1.00-2.00 sec 512 KBytes 4.19 Mbits/sec 4 120 KBytes [ 5] 2.00-3.00 sec 2.12 MBytes 17.8 Mbits/sec 6 360 KBytes [ 5] 3.00-4.00 sec 27.1 MBytes 228 Mbits/sec 6 1.11 MBytes [ 5] 4.00-5.00 sec 38.2 MBytes 321 Mbits/sec 0 1.99 MBytes [ 5] 5.00-6.00 sec 38.2 MBytes 321 Mbits/sec 0 2.46 MBytes [ 5] 6.00-7.00 sec 69.2 MBytes 581 Mbits/sec 71 3.63 MBytes [ 5] 7.00-8.00 sec 110 MBytes 919 Mbits/sec 0 5.92 MBytes * 271 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.12 MBytes 9.43 Mbits/sec 0 320 KBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 600 KBytes [ 5] 2.00-3.00 sec 512 KBytes 4.19 Mbits/sec 7 420 KBytes [ 5] 3.00-4.00 sec 896 KBytes 7.34 Mbits/sec 8 60.0 KBytes [ 5] 4.00-5.00 sec 2.62 MBytes 22.0 Mbits/sec 13 420 KBytes [ 5] 5.00-6.00 sec 12.1 MBytes 102 Mbits/sec 7 1020 KBytes [ 5] 6.00-7.00 sec 19.9 MBytes 167 Mbits/sec 0 1.82 MBytes [ 5] 7.00-8.00 sec 17.9 MBytes 150 Mbits/sec 44 1.76 MBytes [ 5] 8.00-9.00 sec 57.4 MBytes 481 Mbits/sec 30 2.70 MBytes [ 5] 9.00-10.00 sec 88.0 MBytes 738 Mbits/sec 0 6.45 MBytes * 292 ms, ~ 600 Mbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.12 MBytes 9.43 Mbits/sec 0 450 KBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 3 180 KBytes [ 5] 2.00-3.00 sec 640 KBytes 5.24 Mbits/sec 4 120 KBytes [ 5] 3.00-4.00 sec 384 KBytes 3.15 Mbits/sec 2 120 KBytes [ 5] 4.00-5.00 sec 4.50 MBytes 37.7 Mbits/sec 1 660 KBytes [ 5] 5.00-6.00 sec 13.0 MBytes 109 Mbits/sec 3 960 KBytes [ 5] 6.00-7.00 sec 64.5 MBytes 541 Mbits/sec 0 2.17 MBytes * 327 ms, 1 Gbps: [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.12 MBytes 9.43 Mbits/sec 0 600 KBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 4 240 KBytes [ 5] 2.00-3.00 sec 768 KBytes 6.29 Mbits/sec 4 120 KBytes [ 5] 3.00-4.00 sec 1.62 MBytes 13.6 Mbits/sec 5 120 KBytes [ 5] 4.00-5.00 sec 1.88 MBytes 15.7 Mbits/sec 0 480 KBytes [ 5] 5.00-6.00 sec 17.6 MBytes 148 Mbits/sec 14 1.05 MBytes [ 5] 6.00-7.00 sec 35.1 MBytes 295 Mbits/sec 0 2.58 MBytes [ 5] 7.00-8.00 sec 45.2 MBytes 380 Mbits/sec 0 4.63 MBytes [ 5] 8.00-9.00 sec 27.0 MBytes 226 Mbits/sec 96 3.93 MBytes [ 5] 9.00-10.00 sec 85.9 MBytes 720 Mbits/sec 67 4.22 MBytes [ 5] 10.00-11.00 sec 118 MBytes 986 Mbits/sec 0 9.67 MBytes [ 5] 11.00-12.00 sec 124 MBytes 1.04 Gbits/sec 0 15.9 MBytes For short transfers, we strictly stick to the available sending buffer size to (almost) make sure we avoid local retransmissions, and significantly decrease transfer time as a result: from 1.2 s to 60 ms for a 5 MB HTTP transfer from a container hosted in a virtual machine to another guest. v2: - Add 1/9, factoring out a generic version of the scaling function we already use for tcp_get_sndbuf(), as I'm now using it in 7/9 as well - in 3/9, use 4 bits instead of 3 to represent the RTT, which is important as we now use RTT values for more than just the ACK checks - in 5/9, instead of just comparing the sending buffer to SNDBUF_BIG to decide when to acknowledge data, use an adaptive approach based on the bandwidth-delay product - in 6/9, clarify the relationship between SWS avoidance and Nagle's algorithm, and introduce a reference to RFC 813, Section 4 - in 7/9, use an adaptive approach based on the product of bytes sent (and acknowledged) so far and RTT, instead of the previous approach based on bytes sent only, as it allows us to converge to the expected throughput much quicker with high RTT destinations Stefano Brivio (9): tcp, util: Add function for scaling to linearly interpolated factor, use it tcp: Limit advertised window to available, not total sending buffer size tcp: Adaptive interval based on RTT for socket-side acknowledgement checks tcp: Don't clear ACK_TO_TAP_DUE if we're advertising a zero-sized window tcp: Acknowledge everything if it looks like bulk traffic, not interactive tcp: Don't limit window to less-than-MSS values, use zero instead tcp: Allow exceeding the available sending buffer size in window advertisements tcp: Send a duplicate ACK also on complete sendmsg() failure tcp: Skip redundant ACK on partial sendmsg() failure README.md | 2 +- tcp.c | 168 ++++++++++++++++++++++++++++++++++++++++++----------- tcp_conn.h | 9 +++ util.c | 52 +++++++++++++++++ util.h | 2 + 5 files changed, 197 insertions(+), 36 deletions(-) -- 2.43.0

2 24

[PATCH] tcp: Use less-than-MSS window on no queued data, or no data sent recently
by Stefano Brivio 15 Dec '25

15 Dec '25

We limit the advertised window to guests and containers to the available length of the sending buffer, and if it's less than the MSS, since commit cf1925fb7b77 ("tcp: Don't limit window to less-than-MSS values, use zero instead"), we approximate that limit to zero. This way, we'll trigger a window update as soon as we realise that we can advertise a larger value, just like we do in all other cases where we advertise a zero-sized window. By doing that, we don't wait for the peer to send us data before we update the window. This matters because the guest or container might be trying to aggregate more data and won't send us anything at all if the advertised window is too small. However, this might be problematic in two situations: 1. one, reported by Tyler, where the remote (receiving) peer advertises a window that's smaller than what we usually get and very close to the MSS, causing the kernel to give us a starting size of the buffer that's less than the MSS we advertise to the guest or container. If this happens, we'll never advertise a non-zero window after the handshake, and the container or guest will never send us any data at all. With a simple 'curl https://cloudflare.com/', we get, with default TCP memory parameters, a 65535-byte window from the peer, and 46080 bytes of initial sending buffer from the kernel. But we advertised a 65480-byte MSS, and we'll never actually receive the client request. This seems to be specific to Cloudflare for some reason, probably deriving from a particular tuning of TCP parameters on their servers. 2. another one, hypothesised by David, where the peer might only be willing to process (and acknowledge) data in batches. We might have queued outbound data which is, at the same time, not enough to fill one of these batches and be acknowledged and removed from the sending queue, but enough to make our available buffer smaller than the MSS, and the connection will hang. Take care of both cases by: a. not approximating the sending buffer to zero if we have no outboud queued data at all, because in that case we don't expect the available buffer to increase if we don't send any data, so there's no point in waiting for it to grow larger than the MSS. This fixes problem 1. above. b. also using the full sending buffer size if we haven't send data to the socket for a while (reported by tcpi_last_data_sent). This part was already suggested by David in: https://archives.passt.top/passt-dev/aTZzgtcKWLb28zrf@zatzit/ and I'm now picking ten times the RTT as a somewhat arbitrary threshold. This is meant to take care of potential problem 2. above, but it also happens to fix 1. Reported-by: Tyler Cloud <tcloud(a)redhat.com> Link: https://bugs.passt.top/show_bug.cgi?id=183 Suggested-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- tcp.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/tcp.c b/tcp.c index 81bc114..b179e39 100644 --- a/tcp.c +++ b/tcp.c @@ -1211,8 +1211,21 @@ int tcp_update_seqack_wnd(const struct ctx *c, struct tcp_tap_conn *conn, * the MSS to zero, as we already have mechanisms in place to * force updates after the window becomes zero. This matches the * suggestion from RFC 813, Section 4. + * + * But don't do this if, either: + * + * - there's nothing in the outbound queue: the size of the + * sending buffer is limiting us, and it won't increase if we + * don't send data, so there's no point in waiting, or + * + * - we haven't sent data in a while (somewhat arbitrarily, ten + * times the RTT), as that might indicate that the receiver + * will only process data in batches that are large enough, + * but we won't send enough to fill one because we're stuck + * with pending data in the outbound queue */ - if (limit < MSS_GET(conn)) + if (limit < MSS_GET(conn) && sendq && + tinfo->tcpi_last_data_sent < tinfo->tcpi_rtt / 1000 * 10) limit = 0; new_wnd_to_tap = MIN((int)tinfo->tcpi_snd_wnd, limit); -- 2.43.0

2 2

[PATCH 0/5] RFC: Forwarding table data structure
by David Gibson 13 Dec '25

13 Dec '25

Here's some patches starting to create a data structure to store more flexible (and eventually dynamically updateable) forwarding configuration. So far this is just creating the data structures, not actually using them to drive the rest of the code, so it's not ready for merge (but the preliminaries in 1..2/5 could be merged if you like). Putting it out there for early review. David Gibson (5): tcp: Remove extra space from TCP_INFO debug messages (trivial) conf, fwd: Move initialisation of auto port scanning out of conf() conf, fwd: Keep a table of our port forwarding configuration conf: Accurately record ifname and address for outbound forwards conf, fwd: Record "auto" port forwards in forwarding table conf.c | 140 +++++++++++++++++++++++++++++++++++++++++--------------- fwd.c | 78 +++++++++++++++++++++++++++++++ fwd.h | 33 +++++++++++++ passt.c | 1 + tcp.c | 2 +- 5 files changed, 216 insertions(+), 38 deletions(-) -- 2.52.0

2 4

[PATCH v2 0/3] Improved exit()/_exit() handling
by David Gibson 13 Dec '25

13 Dec '25

As discussed on IRC, while working on the forwarding extensions, I discovered that failures at certain points of initialisation (in particular tcp_init() or udp_init() can result in a zombie pasta child process. Here's a fix. v2: * Fix a typo * Use PR_SET_PDEATHSIG instead of explicit kill() * Include updated version of Laurent's cppcheck bug workaround David Gibson (2): treewide: Introduce passt_exit() helper pasta: Clean up waiting pasta child on failures Laurent Vivier (1): tcp: Suppress new instance of cppcheck bug 14191 conf.c | 11 ++++------- log.h | 9 +++++++-- passt.c | 5 ++--- pasta.c | 21 +++++++++++++++------ tap.c | 6 ++---- tcp.c | 10 ++++++---- util.c | 25 +++++++++++++++++++------ util.h | 1 - vhost_user.c | 4 ++-- 9 files changed, 57 insertions(+), 35 deletions(-) -- 2.52.0

2 3