tools/testing/selftests/net/mptcp/mptcp_sockopt.sh | 2 +- tools/testing/selftests/net/mptcp/simult_flows.sh | 34 ++++++++++++---------- 2 files changed, 19 insertions(+), 17 deletions(-)
Bufferbloat is baaaad, even in our selftests: let's kill it (or at least
reduce it). By doing that, the tests (seem to) have a more stable
transfer, and are then less unstable. That's what patches 1-2 are doing,
and they can be backported up to 5.10.
Patch 3 is not related: a small fix in the selftests to remove temp
files that were not deleted in some conditions, since v5.13.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Geliang Tang (1):
selftests: mptcp: sockopt: set EXIT trap earlier
Matthieu Baerts (NGI0) (2):
selftests: mptcp: simult_flows: disable GSO
selftests: mptcp: simult_flows: adapt limits
tools/testing/selftests/net/mptcp/mptcp_sockopt.sh | 2 +-
tools/testing/selftests/net/mptcp/simult_flows.sh | 34 ++++++++++++----------
2 files changed, 19 insertions(+), 17 deletions(-)
---
base-commit: dd433671fef381fdaf7b530c631e6b782d66e224
change-id: 20260527-net-mptcp-sft-bufferbloat-exit-8059196adce4
Best regards,
--
Matthieu Baerts (NGI0) <matttbe@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 27 May 2026 22:11:33 +1000 you wrote:
> Bufferbloat is baaaad, even in our selftests: let's kill it (or at least
> reduce it). By doing that, the tests (seem to) have a more stable
> transfer, and are then less unstable. That's what patches 1-2 are doing,
> and they can be backported up to 5.10.
>
> Patch 3 is not related: a small fix in the selftests to remove temp
> files that were not deleted in some conditions, since v5.13.
>
> [...]
Here is the summary with links:
- [net,1/3] selftests: mptcp: simult_flows: disable GSO
https://git.kernel.org/netdev/net-next/c/0f1fd73c2204
- [net,2/3] selftests: mptcp: simult_flows: adapt limits
https://git.kernel.org/netdev/net-next/c/b7c746a8eeea
- [net,3/3] selftests: mptcp: sockopt: set EXIT trap earlier
https://git.kernel.org/netdev/net-next/c/c8da80af2838
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
On Wed, 27 May 2026 22:11:33 +1000 Matthieu Baerts (NGI0) wrote: > Bufferbloat is baaaad, even in our selftests: let's kill it (or at least > reduce it). By doing that, the tests (seem to) have a more stable > transfer, and are then less unstable. That's what patches 1-2 are doing, > and they can be backported up to 5.10. Could you explain a little more what this is actually fixing? Does it give a huge increase in test stability?
Hi Jakub, On 29/05/2026 07:42, Jakub Kicinski wrote: > On Wed, 27 May 2026 22:11:33 +1000 Matthieu Baerts (NGI0) wrote: >> Bufferbloat is baaaad, even in our selftests: let's kill it (or at least >> reduce it). By doing that, the tests (seem to) have a more stable >> transfer, and are then less unstable. That's what patches 1-2 are doing, >> and they can be backported up to 5.10. > > Could you explain a little more what this is actually fixing? The simult_flows.sh test simulates very low speed links using netem qdiscs. With the current configuration, still a large amount of packets can be queued, which means high TCP RTT samples and then large receive buffer size. Minimal inaccuracy in the pacing rate can lead to using only one subflow towards the end of the connection for a considerable amount of data, while the test expects to use the 2 available paths in parallel. > Does it give a huge increase in test stability? I would say no: the test was not that flaky, mainly on NIPA in fact, and around 4% in the last 100 tests [1]. On my side, I had to get my system busy to reproduce the issues. My hope is that the success rate on NIPA switches from 96 to ~100%. No failure since its introduction in "net-next-2026-05-27--15-00". I sent them to net, just to increase the stability when validating stable kernels as well. But all of this is not urgent, and this series can be applied in net-next if preferred. Do you want me to resend this series targeting net-next? [1] https://netdev.bots.linux.dev/flakes.html?tn-needle=simult-flows-sh Cheers, Matt -- Sponsored by the NGI0 Core fund.
On Fri, 29 May 2026 09:13:44 +1000 Matthieu Baerts wrote: > Hi Jakub, > > On 29/05/2026 07:42, Jakub Kicinski wrote: > > On Wed, 27 May 2026 22:11:33 +1000 Matthieu Baerts (NGI0) wrote: > >> Bufferbloat is baaaad, even in our selftests: let's kill it (or at least > >> reduce it). By doing that, the tests (seem to) have a more stable > >> transfer, and are then less unstable. That's what patches 1-2 are doing, > >> and they can be backported up to 5.10. > > > > Could you explain a little more what this is actually fixing? > > The simult_flows.sh test simulates very low speed links using netem > qdiscs. With the current configuration, still a large amount of packets > can be queued, which means high TCP RTT samples and then large receive > buffer size. Minimal inaccuracy in the pacing rate can lead to using > only one subflow towards the end of the connection for a considerable > amount of data, while the test expects to use the 2 available paths in > parallel. > > > Does it give a huge increase in test stability? > I would say no: the test was not that flaky, mainly on NIPA in fact, and > around 4% in the last 100 tests [1]. On my side, I had to get my system > busy to reproduce the issues. My hope is that the success rate on NIPA > switches from 96 to ~100%. No failure since its introduction in > "net-next-2026-05-27--15-00". > > I sent them to net, just to increase the stability when validating > stable kernels as well. But all of this is not urgent, and this series > can be applied in net-next if preferred. Do you want me to resend this > series targeting net-next? Thanks for explaining, I will take these via net-next, no problem.
© 2016 - 2026 Red Hat, Inc.