Re: [PATCH v7 mptcp-next 0/7] mptcp: address stall under memory pressure

[gang.yan@linux.dev]

May 20, 2026 at 4:19 PM, "Paolo Abeni" <pabeni@redhat.com mailto:pabeni@redhat.com?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:


> 
> On 5/20/26 8:32 AM, Geliang Tang wrote:
> 
> > 
> > On Tue, 2026-05-19 at 19:01 +0200, Paolo Abeni wrote:
> > 
> > > 
> > > This an attempt to fix the data transfer stall reported by Geliang
> > >  and
> > >  Gang more carefully enforcing memory constraints at the MPTCP level.
> > > 
> > >  This iteration presents a significant change WRT the previous one,
> > >  avoiding entirely the collapse attempt on memory pressure. Note that
> > >  this choice represent a trade off: collapsing allow much faster
> > >  transfer
> > >  (to be more accurate: order of magnitude less slow) under some
> > >  extreme
> > >  conditions, but makes transfer slower and much more CPU intensive for
> > >  less unlikely conditions.
> > > 
> > >  As a consequence of the above the `mptcp_data.multi_chunk_sendfile`
> > >  test-case needs a 240 seconds timeout to complete successfully:
> > > 
> > >  TEST_F_TIMEOUT(mptcp, multi_chunk_sendfile, 240)
> > > 
> > >  The solution performing data collapsing would need similar long
> > >  timeout
> > >  for the multiproc tests cases: mutliproc_even, mutliproc_readers,
> > >  mutliproc_writers, mutliproc_sendpage_even,
> > >  mutliproc_sendpage_readers,
> > >  mutliproc_sendpage_writers.
> > > 
> >  
> >  Based on this version, I actually tested the MPTCP TLS self-tests and
> >  still encountered a few similar errors, with the test duration taking
> >  several times longer than before.
> > 
> [...]
> 
> > 
> > ... ...
> >  # # RUN tls.12_aes_gcm_mptcp.multi_chunk_sendfile ...
> >  # # multi_chunk_sendfile: Test terminated by timeout
> >  # # FAIL tls.12_aes_gcm_mptcp.multi_chunk_sendfile
> >  # not ok 3 tls.12_aes_gcm_mptcp.multi_chunk_sendfile
> > 
> Without this series you should get some stall there, right?
> 
> Note that the 'multi_chunk' test will require increasing the test-case timeout,
> as mentioned in v3:
> 
> ---
> diff --git a/tools/testing/selftests/net/mptcp/mptcp_data.c b/tools/testing/selftests/net/mptcp/mptcp_data.c
> index 39d092e7888d..127d8b47bd39 100644
> --- a/tools/testing/selftests/net/mptcp/mptcp_data.c
> +++ b/tools/testing/selftests/net/mptcp/mptcp_data.c
> @@ -166,7 +166,7 @@ static void chunked_sendfile(struct __test_metadata *_metadata,
>  close(fd);
>  }
>  
> -TEST_F(mptcp, multi_chunk_sendfile)
> +TEST_F_TIMEOUT(mptcp, multi_chunk_sendfile, 240)
>  {
>  chunked_sendfile(_metadata, self, 4096, 4096);
>  chunked_sendfile(_metadata, self, 4096, 0);
> 
> ---
> 
Hi Paolo,

No offense intended at all— Geliang and I just wanted to confirm
whether this performance regression is expected, acceptable, or
something we can optimize further.

We tested the performance of mptcp_data.sh (time per run) 15 times
under the v7 patch and [1], and the results are as follows:

v7 results:
5.82 4.72 5.38 6.18 6.52 6.04 5.05 6.49 4.78 5.62 5.52 4.91 8.07 3.87 5.61

    Max: 8.07s, Min: 3.87s, Avg: 5.64s

[1] results:
2.98 3.44 3.11 3.06 3.78 3.23 3.28 2.88 3.52 3.33 2.89 3.33 3.91 3.20 3.45

    Max: 3.91s, Min: 2.88s, Avg: 3.29s

We’d appreciate your thoughts on whether this delta aligns with
expectations, or if there are further optimizations we should explore.


[1] https://patchwork.kernel.org/project/mptcp/cover/cover.1773735950.git.yangang@kylinos.cn/

Thanks
Gang

> The timeout could be reduced/avoided, including the 'collapse' strategy from v5
> and previous revisions. As hinted by Eric, collapsing is a sort of weak spot
> for potential evil peers and in practice causes high CPU usage increase to the
> point that in debug build some other test-cases will still require an increased
> timeout. 
> 
> AFAICS the multi chunk is really a corner case, especially when sending
> 1 byte chunk. As a trade off I prefer avoiding collapsing, and accept any
> solution that allow completion in the multi chunk test, even with very low
> tput. 
> 
> Side note: I think/I'm reasonably sure even plain TCP will have hard time
> with such that case in comparable conditions, i.e. when OoO happens with
> very high probability _after_ that the sender start pushing data at high speed, 
> but the upstream self-tests (rightfully) do not include the OoO part.
> 
> /P
>