Re: [PATCH mptcp-next] selftests: mptcp: more stable simult_flows tests

[Matthieu Baerts <matttbe@kernel.org>]

Hi Paolo,

On 16/02/2026 22:20, Paolo Abeni wrote:
> By default, the netem qdisc can keep up to 1000 packets under its belly
> to deal with the configured rate and delay. The simult flows test-case
> simulates very low speed links, to avoid problems due to slow CPUs and
> the TCP stack tend to transmit at a slightly higher rate than the
> (virtual) link constraints.
> 
> All the above causes a relatively large amount of packets being enqueued
> in the netem qdiscs - the longer the transfer, the longer the queue -
> producing increasingly high TCP RTT samples and consequently increasingly
> larger receive buffer size due to DRS.
> 
> When the receive buffer size becomes considerably larger than the needed
> size, the tests results can flake, i.e. because minimal inaccuracy in the
> pacing rate can lead to a single subflow usage towards the end of the
> connection for a considerable amount of data.
> 
> Address the issue explicitly setting netem limits suitable for the
> configured link speeds and unflake all the affected tests.

Thank you for having taken the time to analyse this, and provided a fix!
Bufferbloat is a plague, even in the selftests!

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

I suggest applying this in -net, hopefully to help to validate stable
kernel versions.

> Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
>  tools/testing/selftests/net/mptcp/simult_flows.sh | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/testing/selftests/net/mptcp/simult_flows.sh b/tools/testing/selftests/net/mptcp/simult_flows.sh
> index a9c9927d6cbc..d11a8b949aab 100755
> --- a/tools/testing/selftests/net/mptcp/simult_flows.sh
> +++ b/tools/testing/selftests/net/mptcp/simult_flows.sh
> @@ -237,10 +237,13 @@ run_test()
>  	for dev in ns2eth1 ns2eth2; do
>  		tc -n $ns2 qdisc del dev $dev root >/dev/null 2>&1
>  	done
> -	tc -n $ns1 qdisc add dev ns1eth1 root netem rate ${rate1}mbit $delay1
> -	tc -n $ns1 qdisc add dev ns1eth2 root netem rate ${rate2}mbit $delay2
> -	tc -n $ns2 qdisc add dev ns2eth1 root netem rate ${rate1}mbit $delay1
> -	tc -n $ns2 qdisc add dev ns2eth2 root netem rate ${rate2}mbit $delay2
> +
> +	# keep the queued pkts number low, or the RTT estimator will see
> +	# increasing latency over time.
> +	tc -n $ns1 qdisc add dev ns1eth1 root netem rate ${rate1}mbit $delay1 limit 50
> +	tc -n $ns1 qdisc add dev ns1eth2 root netem rate ${rate2}mbit $delay2 limit 50
> +	tc -n $ns2 qdisc add dev ns2eth1 root netem rate ${rate1}mbit $delay1 limit 50
> +	tc -n $ns2 qdisc add dev ns2eth2 root netem rate ${rate2}mbit $delay2 limit 50
>  
>  	# time is measured in ms, account for transfer size, aggregated link speed
>  	# and header overhead (10%)
> @@ -304,7 +307,7 @@ run_test 10 10 1 25 "balanced bwidth with unbalanced delay"
>  # we still need some additional infrastructure to pass the following test-cases
>  MPTCP_LIB_SUBTEST_FLAKY=1 run_test 10 3 0 0 "unbalanced bwidth"

By any chance, did you check if your modification was helping this case
as well? If not, I can try on my side when I have the opportunity (no
urgency anyway).

>  run_test 10 3 1 25 "unbalanced bwidth with unbalanced delay"
> -MPTCP_LIB_SUBTEST_FLAKY=1 run_test 10 3 25 1 "unbalanced bwidth with opposed, unbalanced delay"
> +run_test 10 3 25 1 "unbalanced bwidth with opposed, unbalanced delay"
>  
>  mptcp_lib_result_print_all_tap
>  exit $ret

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.