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

[Paolo Abeni <pabeni@redhat.com>]

On 2/18/26 1:13 PM, Matthieu Baerts wrote:
> 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).

I'm still investigating the overall scenarios, but AFAICS we still need
the FLAKY annotation there.

/P