From: Jakub Kicinski <kuba@kernel.org>
To: Matthieu Baerts <matttbe@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: Thu, 28 May 2026 16:39:07 -0700 [thread overview]
Message-ID: <20260528163907.619420c3@kernel.org> (raw)
In-Reply-To: <0e676b57-ca1a-4f2b-8166-a085fe69e0f2@kernel.org>
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.
next prev parent reply other threads:[~2026-05-28 23:39 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
2026-05-28 23:39 ` Jakub Kicinski [this message]
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=20260528163907.619420c3@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martineau@kernel.org \
--cc=matttbe@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.