From: Matthieu Baerts <matttbe@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Mat Martineau <martineau@kernel.org>,
Geliang Tang <geliang@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Shuah Khan <shuah@kernel.org>, Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org, mptcp@lists.linux.dev,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net 0/3] selftests: mptcp: reduce bufferbloat and cleanup
Date: Fri, 29 May 2026 09:13:44 +1000 [thread overview]
Message-ID: <0e676b57-ca1a-4f2b-8166-a085fe69e0f2@kernel.org> (raw)
In-Reply-To: <20260528144258.58bbc950@kernel.org>
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.
next prev parent reply other threads:[~2026-05-28 23:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 12:11 [PATCH net 0/3] selftests: mptcp: reduce bufferbloat and cleanup Matthieu Baerts (NGI0)
2026-05-27 12:11 ` [PATCH net 1/3] selftests: mptcp: simult_flows: disable GSO Matthieu Baerts (NGI0)
2026-05-27 12:11 ` [PATCH net 2/3] selftests: mptcp: simult_flows: adapt limits Matthieu Baerts (NGI0)
2026-05-27 12:11 ` [PATCH net 3/3] selftests: mptcp: sockopt: set EXIT trap earlier Matthieu Baerts (NGI0)
2026-05-28 21:42 ` [PATCH net 0/3] selftests: mptcp: reduce bufferbloat and cleanup Jakub Kicinski
2026-05-28 23:13 ` Matthieu Baerts [this message]
2026-05-28 23:39 ` Jakub Kicinski
2026-05-28 23:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e676b57-ca1a-4f2b-8166-a085fe69e0f2@kernel.org \
--to=matttbe@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox