On Wed, Jul 08, 2026 at 07:00:00AM -0400, Michael S. Tsirkin wrote:
On Wed, Jul 08, 2026 at 12:29:03PM +0200, Stefano Garzarella wrote:
From: Stefano Garzarella <[email protected]>
When many small packets accumulate in the receive queue, the skb overhead
can exceed buf_alloc even while the payload is within bounds. This causes
virtio_transport_inc_rx_pkt() to reject packets, leading to connection
resets during large transfers under backpressure.
The issue was reported by Brien, who has a reproducer, but it is also
easily reproducible with iperf-vsock [1] using a small packet size:
iperf3 --vsock -c $CID -l 129
which fails immediately without this patch but with commit 059b7dbd20a6
("vsock/virtio: fix potential unbounded skb queue").
Inspired by TCP's tcp_collapse() which solves a similar problem, add
virtio_transport_collapse_rx_queue() that walks the receive queue and
re-copies data into compact linear skbs to reduce the overhead.
The collapse is triggered proactively from when the number of skb queued
is close to exceeding the overhead budget.
A pre-scan counts the eligible bytes to size each allocation precisely,
avoiding waste for isolated small packets. Partially consumed skbs are
kept as-is to preserve buf_used/fwd_cnt accounting, EOM-marked skbs to
maintain SEQPACKET message boundaries, and skbs already larger than the
collapse target because they already have a good data-to-overhead ratio.
Walking a large queue may take a significant amount of time and cache
misses, causing traffic burstiness. To limit this, the collapse stops
once enough room is freed for this packet and the next one, but may
opportunistically free more to fill each collapsed skb to capacity.
[1] https://github.com/stefano-garzarella/iperf-vsock
Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue")
Cc: [email protected]
Reported-by: Brien Oberstein <[email protected]>
Closes:
https://lore.kernel.org/netdev/[email protected]/
Tested-by: Brien Oberstein <[email protected]>
Signed-off-by: Stefano Garzarella <[email protected]>
this is the right approach
Yeah, I have a follow up to start to use skb->truesize, etc. but I guess
more net-next material.
Acked-by: Michael S. Tsirkin <[email protected]>
Thanks,
Stefano
