Re: [PATCH net-next v8 9/9] selftests: net: Add a test for BIG TCP in UDP tunnels

["Alice Mikityanska" <alice.kernel@fastmail.im>]

On Tue, Jul 7, 2026, at 17:12, Matthieu Baerts wrote:
> Hi Alice,
>
> On 07/07/2026 10:40, Alice Mikityanska wrote:
>> On Tue, Jul 7, 2026, at 11:06, Paolo Abeni wrote:
>>> On 7/6/26 8:19 PM, Alice Mikityanska wrote:
>
> (...)
>
>>>> +
>>>> +cleanup_tunnel() {
>>>> +	ip -netns "$CLIENT_NS" link del tun0
>>>> +	ip -netns "$SERVER_NS" link del tun1
>>>> +}
>>>> +
>>>> +cleanup() {
>>>> +	ip netns pids "$SERVER_NS" | xargs -r kill
>>>> +	ip netns pids "$CLIENT_NS" | xargs -r kill
>>>> +	ip netns del "$SERVER_NS"
>>>> +	ip netns del "$CLIENT_NS"
>>>> +	rm -rf "$WORKDIR"
>>>> +}
>>>> +
>>>> +do_test() {
>>>> +	# When tx csum offload is off, software GSO is performed before passing the
>>>> +	# packet to veth. Check BIG TCP packets inside the VXLAN tunnel to verify
>>>> +	# the software checksum path: if the checksum code is broken, these packets
>>>> +	# will be dropped.
>>>> +	if [ "$2" = on ]; then
>>>> +		CAPTURE_IFACE='link'
>>>> +	else
>>>> +		CAPTURE_IFACE='tun'
>>>> +	fi
>>>> +
>>>> +	ip netns exec "$SERVER_NS" tcpdump -nn -s 256 -i "${CAPTURE_IFACE}1" greater 65536 -w "$WORKDIR/server.pcap" 2> /dev/null &
>>>> +	TCPDUMP_SERVER_PID="$!"
>>>> +	ip netns exec "$CLIENT_NS" tcpdump -nn -s 256 -i "${CAPTURE_IFACE}0" greater 65536 -w "$WORKDIR/client.pcap" 2> /dev/null &
>>>> +	TCPDUMP_CLIENT_PID="$!"
>>>> +
>>>> +	# This filter doesn't capture all possible variants of SACK, but it's aimed
>>>> +	# at the typical one where SACK follows after [nop, nop, timestamp, nop,
>>>> +	# nop] (14 bytes after the 20-byte TCP header). IPv6 needs a separate match,
>>>> +	# because man tcpdump says:
>>>> +	# > Arithmetic expression against transport layer headers, like tcp[0], does
>>>> +	# > not work against IPv6 packets.  It only looks at IPv4 packets.
>>>> +	ip netns exec "$SERVER_NS" tcpdump -nn -s 256 -i "tun1" '(tcp[tcpflags] & (tcp-syn|tcp-ack) = tcp-ack and tcp[34:2] & 0xffc3 = 0x0502) or (ip6[6] = 0x06 and ip6[53] & 0x12 = 0x10 and ip6[74:2] & 0xffc3 = 0x0502)' -w "$WORKDIR/sack.pcap" 2> /dev/null &
>
> The tcpdump commands might need to be used with ...
>
>   --immediate-mode --packet-buffered
>
> ... but that's maybe not needed, see below.

Thanks! I was aware of these options, but I was afraid they'd slow down
tcpdump and let it drop some packets. Well, now that I actually tested
them, it seems that my concern was not valid. I'll add these and drop
the second sleep (if I stay with tcpdump).

>>>> +	TCPDUMP_SACK_PID="$!"
>>>> +
>>>> +	if [ "$1" = 4 ]; then
>>>> +		SERVER_IP="$SERVER_IP4_TUN"
>>>> +		echo "Running IPv4 traffic in the tunnel"
>>>> +	else
>>>> +		SERVER_IP="$SERVER_IP6_TUN"
>>>> +		echo "Running IPv6 traffic in the tunnel"
>>>> +	fi
>>>> +
>>>> +	sleep 1 # Give tcpdump a second to spin up.
>
> This is possibly not needed, see below.
>
>>>> +	ip netns exec "$CLIENT_NS" netperf -t TCP_STREAM -l 5 -H "$SERVER_IP" -- \
>>>> +		-m 80000 > /dev/null
>>>> +	sleep 1 # Give tcpdump a second to process buffered packets.
>>>> +	kill "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID" "$TCPDUMP_SACK_PID"
>>>> +	wait "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID" "$TCPDUMP_SACK_PID"
>>>> +	PACKETS_SERVER=$(tcpdump --count -r "$WORKDIR/server.pcap" 2> /dev/null | cut -d ' ' -f 1)
>>>> +	PACKETS_CLIENT=$(tcpdump --count -r "$WORKDIR/client.pcap" 2> /dev/null | cut -d ' ' -f 1)
>>>> +	PACKETS_SACK=$(tcpdump --count -r "$WORKDIR/sack.pcap" 2> /dev/null | cut -d ' ' -f 1)
>>>> +
>>>> +	echo "Captured BIG TCP RX packets: $PACKETS_SERVER"
>>>> +	echo "Captured BIG TCP TX packets: $PACKETS_CLIENT"
>>>> +	echo "Captured TCP SACK packets: $PACKETS_SACK"
>>>> +	[ "$PACKETS_SERVER" -gt "$PACKETS_THRESHOLD" ] || return 1
>>>> +	[ "$PACKETS_CLIENT" -gt "$PACKETS_THRESHOLD" ] || return 1
>>>> +	[ "$PACKETS_SACK" -lt "$(( PACKETS_CLIENT / 2 ))" ] || return 1
>>>
>>> KCI fails here, see:
>>>
>>> https://netdev-ctrl.bots.linux.dev/logs/vmksft/net/results/722863/156-big-tcp-tunnels-sh/stdout
>>>
>>> possibly the above parsing is a bit fragile/tcpdump version's dependent?!?
>> 
>> TL/DR: I've seen this when I ran out of space in /tmp before adding -s 256.
>> 
>> Hmm, the changes I made in this iteration were aimed at addressing version-
>> dependent behavior of tcpdump... I used to count the lines of its
>> output. Newer tcpdump prints two lines per encapsulated packet. Older
>> tcpdump can't parse BIG TCP in this test and prints one line per packet.
>> To make it more robust, I decided to store the pcap and count the
>> packets there (--count doesn't work with live capture when tcpdump is
>> interrupted). The pitfall is that now it takes a few hundred megabytes
>> in /tmp to store those pcaps.
>
> Wow :)
>
> If you need to keep tcpdump -- see below -- you can probably reduce even
> more the packet size (-s 256), I don't know what's the minimum. And
> purge the workdir in cleanup_tunnel().

Apparently, the overflow in /tmp happens during one single test, because
the files are not accumulated: the next test overwrites the same files.

>> Now, seeing empty stdout from tcpdump could be if the pcap file is empty
>> (doesn't contain the pcap header), because we ran out of space in /tmp
>> (first two tcpdumps took all space, the third didn't write the header -
>> I observed this behavior before I added -s 256). We don't see the
>> corresponding error messages, because tcpdump starts with 2> /dev/null
>> (otherwise it floods the screen with statistics). Could this be the
>> reason? How much space is allocated for /tmp in the CI runners?
>> 
>> I can probably address it by limiting the overall number of captured
>> packets with -c, but then I won't be able to compare $PACKETS_SACK
>> relative to $PACKETS_CLIENT.
>
> If you only need to count some packets matching a filter, what about
> using Netfilter rules with a counter, instead of using pcap files?
>
> You can have counters not attached to rules altering packets:
>
>   https://wiki.nftables.org/wiki-nftables/index.php/Counters

Thanks for the suggestion! Yes, I agree, I think, at this point it will
be cleaner to use netfilter counters. By the way, the other test
big_tcp.sh uses an iptables rule, that comes with a counter by default,
to count BIG TCP packets.

> It might even be easier to match the SACK packets, with the 'tcp option
> sack' filter from nft [1].

Great, it will match all sorts of SACK packets, not only the specific
one that my filter does.

Thank you, I'll explore this direction, it looks more promising.

> And for the size, I guess you can use "meta
> length > 65536" [2], or checking other fields from IP/TCP headers.
>
> If you want to keep your cBPF filter, you can also use nfbpf_compile for
> the translation, and use that with 'iptables -m bpf --bytecode <...>',
> but it might not be needed.
>
> [1] 
> https://www.mankier.com/8/nft#Payload_Expressions-Extension_Header_Expressions
> [2] https://www.mankier.com/8/nft#Primary_Expressions-Meta_Expressions
>
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.