On Wed, Jul 24, 2024 at 10:40:15AM +1000, David Gibson wrote:On Tue, Jul 23, 2024 at 10:29:36PM +0200, Stefano Brivio wrote:Found it. Looks like one of the cases where we need to set SO_PEEK_OFF was lost somewhere in the refactorings :(.On Tue, 23 Jul 2024 00:09:37 +0200 Stefano Brivio <sbrivio(a)redhat.com> wrote:Bother. I've reproduced and am debugging now.From: Jon Maloy <jmaloy(a)redhat.com> Based on an original patch by Jon Maloy:...so, with this, the probing issue is solved: on a 6.10 kernel, SO_PEEK_OFF is not used, unless I disable IPv6 (with --ipv4-only / -4). However, if I disable it, for some reason, resorting to IPv4, at least together with the flow table (applying just this patch to HEAD), I get something that looks like one of the "old" TCP stalls. On the host: $ ./passt -f -t 10000 -4 and in the guest: # ip link set dev eth0 up # dhclient eth0 # iperf3 -s -p 10000 back to the host: $ iperf3 -c 127.0.0.1 -p 10000 Connecting to host 127.0.0.1, port 10000 [ 5] local 127.0.0.1 port 39046 connected to 127.0.0.1 port 10000 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 11.2 MBytes 94.3 Mbits/sec 0 5.50 MBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 5.50 MBytes [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 5.50 MBytes ...the transfer never recovers.-- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibsonI didn't really have time to debug this further. At the moment I would be inclined to temporarily revert commit e63d281871ef ("tcp: leverage support of SO_PEEK_OFF socket option when available"), but it's not a good idea if this happens to be hiding some (unlikely?) issue with the flow table.