Re: [PATCH mptcp-net v5 1/5] mptcp: replace backlog_list with backlog_queue

[gang.yan@linux.dev]

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


> 
> On 4/15/26 10:21 AM, gang.yan@linux.dev wrote:
> 
> > 
> > April 15, 2026 at 3:17 PM, "Paolo Abeni" <pabeni@redhat.com mailto:pabeni@redhat.com?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:
> > 
> > > 
> > > AFAICS the stall in the self-tests in patch 5/5 is caused by the sysctl
> > >  setting taking effect on the server side _after_ that the 3whs
> > >  negotiated the initial window; the rcvbuf suddenly shrinks from ~128K to
> > >  4K and almost every incoming packet is dropped.
> > > 
> > >  The test itself is really an extreme condition; we should accept any
> > >  implementation able to complete the transfer - even at very low speed.
> > > 
> > >  The initial test-case, the one using sendfile(), operates in a
> > >  significantly different way: it generates 1-bytes len DSS preventing
> > >  coalescing (I've not understood yet why coalescing does not happen),
> > >  which cause an extremely bad skb->truesize/skb->len ratio, which in turn
> > >  causes the initial window being way too "optimistic", extreme rcvbuf
> > >  squeeze at runtime and a behavior similar to the previous one.
> > > 
> > >  In both cases simply dropping incoming packets early/in
> > >  mptcp_incoming_options() when the rcvbuf is full does not solve the
> > >  issue: if the rcvbuf is used (mostly) by the OoO queue, retransmissions
> > >  always hit the same rcvbuf condition and are also dropped.
> > > 
> > >  The root cause of both scenario is that some very unlikely condition
> > >  calls to retract the announced rcv wnd, but mptcp can't do that.
> > > 
> > >  Currently I start to think that we need a strategy similar to plain TCP
> > >  to deal with such scenario: when rcvbuf is full we need to condense and
> > >  eventually prune the OoO queue (see tcp_prune_queue(),
> > >  tcp_collapse_ofo_queue(), tcp_collapse()).
> > > 
> > >  The above has some serious downsides, i.e. it could lead to large slice
> > >  of almost duplicate complex code, as is diff to abstract the MPTCP vs
> > >  TCP differences (CB, seq numbers, drop reasons). Still under investigation.
> > > 
> > >  /P
> > > 
> >  Hi, Paolo
> >  Thanks a lot for your detailed and insightful analysis of this problem!
> >  
> >  I fully agree with your points: MPTCP should allow the transfer to complete
> >  even under extremely slow or harsh conditions, just as you mentioned.
> > 
> I was likely not clear in my previous message. IMHO the key point is
> that in the mentioned scenario we should consider suitable any fix that
> would allow completing the transfer, even at a extremely low average
> bitrate - because the memory conditions are indeed extreme.
> 
> I.e. we can/should consider this case an extreme slow path.
> 
> > 
> > Regarding the TCP-style mechanisms like 'tcp_prune_queue' for handling full
> >  rcvbuf conditions — I have actually attempted similar implementations before.
> >  As you pointed out, this approach is indeed highly complex for MPTCP. There
> >  are far too many aspects that require careful modification and consideration,
> >  making it extremely challenging to implement correctly.
> > 
> I agree duplicating the TCP pruning code inside MPTCP does not look a
> viable solution.
> 
> I think we can instead share it (at least the most cumbersome helper),
> with some caveat. I have a few very rough patches doing that. Let me add
> some comments to at least somehow make the code readable and I'll share
> them here.
> 

Thank you so much for your help and for working on this!

Looking forward to your updates.

Thanks
Gang

> /P
>