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

[gang.yan@linux.dev]

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


> 
> On 5/18/26 10:13 AM, gang.yan@linux.dev wrote:
> 
> > 
> > May 15, 2026 at 5:29 PM, "Paolo Abeni" <pabeni@redhat.com mailto:pabeni@redhat.com?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:
> > 
> > > 
> > > On 5/15/26 11:07 AM, 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.
> >  
> >  Patch 1 is new in v6, and is actually a fix for an old issue (targeting
> >  net), included here just for my convenience.
> >  
> >  Patch 2 and 3 makes the admission check much more strict for incoming
> >  packets exceeding the memory limits, with some exception for fallback
> >  sockets.
> >  Patch 4 makes implement OoO queue pruning for MPTCP and patch 5
> >  addresses an edge scenario that could still lead to transfer stall
> >  under memory pressure.
> >  Finally patch 6 and 7 improve the MPTCP-level retransmission schema to
> >  make recovery from memory pressure/after MPTCP-level drop significanly
> >  faster.
> > 
> > > 
> > > @Geliang, @Gang: could you please have a spin at this iteration? Note
> > >  that you must increase the timeout for the
> > >  mptcp_data.multi_chunk_sendfile test-case, as mentioned above.
> > > 
> >  Hi Paolo,
> >  
> >  Thanks a lot for the new patch set. We have encountered some issues during
> >  our testing. It will take us some time to analyze and locate the root cause.
> >  We will post updates on the mailing list as soon as we make progress.
> > 
> I run a few hundred iterations of the mptcp_data test without observing
> any issue (still running). Can you please share which issue are you
> observing, the relevant tests case and the build type (debug/non debug)?
> 
> Thanks,
>
Hi Paolo,

Sorry for not providing the specific details earlier in my first message.
The issue we are seeing occurs specifically when KTLS is enabled.

Today I ran several sets of comparative tests (many hundreds iterations), and the
current results suggest that the integration framework between KTLS and MPTCP
may need some adjustments. We are investigating the root cause.

Thanks for your help.

Cherrs,
Gang

> Paolo
>