- dev - passt

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

[PATCH 4/5] conf: Accurately record ifname and address for outbound forwards
by David Gibson 12 Dec '25

12 Dec '25

-T and -U options don't allow specifying a listening address. Usually this will listen on *%lo in the guest. However on kernels without unprivileged SO_BINDTODEVICE that's not possible so we instead listen separately on 127.0.0.1 and ::1. Currently that's handled at the point we actually set up the listens, we record both address and ifname as NULL in the forwarding table entry. That will cause trouble for future extensions we want, so update this to accurately create the forwarding table: either a single entry with ifname == "lo" or two entries with address of 127.0.0.1 and ::1. As a bonus, this gives the user a warning if they specify an explicit outbound forwarding on a kernel without SO_BINDTODEVICE. The existing warning for missing SO_BINDTODEVICE (incorrectly) only covers the case of -T auto or -U auto. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- conf.c | 38 ++++++++++++++++++++++++++++++-------- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/conf.c b/conf.c index 88971d04..b24ab407 100644 --- a/conf.c +++ b/conf.c @@ -157,12 +157,6 @@ static void conf_ports_range_except(const struct ctx *c, char optname, optname, optarg); } - if (ifname && c->no_bindtodevice) { - die( -"Device binding for '-%c %s' unsupported (requires kernel 5.7+)", - optname, optarg); - } - for (base = first; base <= last; base++) { if (bitmap_isset(exclude, base)) continue; @@ -204,8 +198,27 @@ static void conf_ports_range_except(const struct ctx *c, char optname, } } - fwd_table_add(fwd, flags, addr, ifname, - base, i - 1, base + delta); + if ((optname == 'T' || optname == 'U') && c->no_bindtodevice) { + /* FIXME: Once the fwd bitmaps are removed, move this + * workaround to the caller + */ + ASSERT(!addr && ifname && !strcmp(ifname, "lo")); + warn( +"SO_BINDTODEVICE unavailable, forwarding only 127.0.0.1 and ::1 for '-%c %s'", + optname, optarg); + + if (c->ifi4) { + fwd_table_add(fwd, flags, &inany_loopback4, NULL, + base, i - 1, base + delta); + } + if (c->ifi6) { + fwd_table_add(fwd, flags, &inany_loopback6, NULL, + base, i - 1, base + delta); + } + } else { + fwd_table_add(fwd, flags, addr, ifname, + base, i - 1, base + delta); + } base = i - 1; } @@ -352,6 +365,15 @@ static void conf_ports(const struct ctx *c, char optname, const char *optarg, } } while ((p = next_chunk(p, ','))); + if (ifname && c->no_bindtodevice) { + die( +"Device binding for '-%c %s' unsupported (requires kernel 5.7+)", + optname, optarg); + } + /* Outbound forwards come from guest loopback */ + if ((optname == 'T' || optname == 'U') && !ifname) + ifname = "lo"; + if (exclude_only) { /* Exclude ephemeral ports */ for (i = 0; i < NUM_PORTS; i++) -- 2.52.0

1 0

[PATCH 2/5] conf, fwd: Move initialisation of auto port scanning out of conf()
by David Gibson 12 Dec '25

12 Dec '25

We call fwd_scan_ports_init() at (almost) the end of conf(). It's a bit odd to do actual work from a function that's ostensibly about getting our configuration. It's not the only instance of this, but to make things a bit clearer move the call to main(), right after flow_init(). Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- conf.c | 2 -- passt.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/conf.c b/conf.c index 24b44419..2942c8c2 100644 --- a/conf.c +++ b/conf.c @@ -2144,8 +2144,6 @@ void conf(struct ctx *c, int argc, char **argv) if (!c->udp.fwd_out.mode) c->udp.fwd_out.mode = fwd_default; - fwd_scan_ports_init(c); - if (!c->quiet) conf_print(c); } diff --git a/passt.c b/passt.c index cf38822f..7488a84c 100644 --- a/passt.c +++ b/passt.c @@ -396,6 +396,7 @@ int main(int argc, char **argv) die_perror("Failed to get CLOCK_MONOTONIC time"); flow_init(); + fwd_scan_ports_init(&c); if ((!c.no_udp && udp_init(&c)) || (!c.no_tcp && tcp_init(&c))) passt_exit(EXIT_FAILURE); -- 2.52.0

1 0

[PATCH] tcp: Remove extra space from TCP_INFO debug messages (trivial)
by David Gibson 12 Dec '25

12 Dec '25

Debug messages about which tcp_info fields are supported contained an extra space, always ending with " supported". Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- tcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tcp.c b/tcp.c index 1711bcc7..81bc1145 100644 --- a/tcp.c +++ b/tcp.c @@ -2950,7 +2950,7 @@ int tcp_init(struct ctx *c) tcp_info_size = tcp_probe_tcp_info(); #define dbg_tcpi(f_) debug("TCP_INFO tcpi_%s field%s supported", \ - STRINGIFY(f_), tcp_info_cap(f_) ? " " : " not ") + STRINGIFY(f_), tcp_info_cap(f_) ? "" : " not") dbg_tcpi(snd_wnd); dbg_tcpi(bytes_acked); dbg_tcpi(min_rtt); -- 2.52.0

1 0