Re: [PATCH v2 mptcp-next 7/7] mptcp: implemented OoO queue pruning

Hi Matt,

On Thu, 2026-08-06 at 18:46 +0200, Matthieu Baerts wrote:
> On 06/08/2026 18:42, Paolo Abeni wrote:
> > On 8/6/26 4:45 PM, Paolo Abeni wrote:
> > > When moving incoming skbs in the msk receive queue and the latter
> > > is above limits, prune it as needed quite alike what TCP is doing
> > > at the subflow level. The main difference relies in the stop
> > > condition:
> > > since MPTCP does not perform collapsing, it's better off dropping
> > > the
> > > bare minimum to fit the (newer) incoming packet.
> > > 
> > > Signed-off-by: Paolo Abeni <[email protected]>
> > > Tested-by: Gang Yan <[email protected]>
> > > Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
> > > ---
> > > v<n> -> v<n+1>:
> > >   - prune only for new data
> > >   - reorganize the code to follow more closely TCP
> > > ---
> > >  net/mptcp/mib.c      |  1 +
> > >  net/mptcp/mib.h      |  1 +
> > >  net/mptcp/protocol.c | 81
> > > ++++++++++++++++++++++++++++++++++++++------
> > >  3 files changed, 73 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/net/mptcp/mib.c b/net/mptcp/mib.c
> > > index ef65e2df709f..2569385bab7c 100644
> > > --- a/net/mptcp/mib.c
> > > +++ b/net/mptcp/mib.c
> > > @@ -87,6 +87,7 @@ static const struct snmp_mib mptcp_snmp_list[]
> > > = {
> > >  	SNMP_MIB_ITEM("WinProbe", MPTCP_MIB_WINPROBE),
> > >  	SNMP_MIB_ITEM("BacklogDrop", MPTCP_MIB_BACKLOGDROP),
> > >  	SNMP_MIB_ITEM("RcvPruned", MPTCP_MIB_RCVPRUNED),
> > > +	SNMP_MIB_ITEM("OFOPruned", MPTCP_MIB_OFOPRUNED),
> > >  };
> > >  
> > >  /* mptcp_mib_alloc - allocate percpu mib counters
> > > diff --git a/net/mptcp/mib.h b/net/mptcp/mib.h
> > > index 9271205f682e..3a3425e258a7 100644
> > > --- a/net/mptcp/mib.h
> > > +++ b/net/mptcp/mib.h
> > > @@ -90,6 +90,7 @@ enum linux_mptcp_mib_field {
> > >  	MPTCP_MIB_WINPROBE,		/* MPTCP-level zero
> > > window probe */
> > >  	MPTCP_MIB_BACKLOGDROP,		/* Backlog over memory
> > > limit */
> > >  	MPTCP_MIB_RCVPRUNED,		/* Dropped due to memory
> > > constraints */
> > > +	MPTCP_MIB_OFOPRUNED,		/* MPTCP-level OoO queue
> > > pruned */
> > >  	__MPTCP_MIB_MAX
> > >  };
> > >  
> > > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> > > index 63f2c18bc01f..ec874d2ead6a 100644
> > > --- a/net/mptcp/protocol.c
> > > +++ b/net/mptcp/protocol.c
> > > @@ -242,6 +242,65 @@ static bool mptcp_rcvbuf_grow(struct sock
> > > *sk, u32 newval)
> > >  	return false;
> > >  }
> > >  
> > > +/* "Inspired" from the TCP version; main difference: stop as
> > > soon as the MPTCP
> > > + * socket is under memory limit.
> > > + */
> > > +static void mptcp_prune_ofo_queue(struct sock *sk,
> > > +				  const struct sk_buff *in_skb)
> > > +{
> > > +	struct mptcp_sock *msk = mptcp_sk(sk);
> > > +	struct rb_node *node, *prev;
> > > +	bool pruned = false;
> > > +	u64 mem;
> > > +
> > > +	if (RB_EMPTY_ROOT(&msk->out_of_order_queue))
> > > +		return;
> > > +
> > > +	node = &msk->ooo_last_skb->rbnode;
> > > +
> > > +	do {
> > > +		struct sk_buff *skb = rb_to_skb(node);
> > > +
> > > +		/* Stop pruning if the incoming skb would land
> > > in OoO tail. */
> > > +		if (after64(MPTCP_SKB_CB(in_skb)->map_seq,
> > > +			    MPTCP_SKB_CB(skb)->map_seq))
> > > +			break;
> > > +
> > > +		pruned = true;
> > > +		prev = rb_prev(node);
> > > +		rb_erase(node, &msk->out_of_order_queue);
> > > +		mptcp_drop(sk, skb);
> > > +		msk->ooo_last_skb = rb_to_skb(prev);
> > > +
> > > +		mem = (unsigned int)sk_rmem_alloc_get(sk);
> > > +		if (mem <= sk->sk_rcvbuf)
> > > +			break;
> > > +
> > > +		node = prev;
> > > +	} while (node);
> > > +
> > > +	if (pruned)
> > > +		MPTCP_INC_STATS(sock_net(sk),
> > > MPTCP_MIB_OFOPRUNED);
> > > +}
> > > +
> > > +/* The stack can't drop packets for fallback socket at the msk
> > > level, or the
> > > + * stream will break.
> > > + */
> > > +static bool mptcp_can_ingest(const struct sock *sk)
> > > +{
> > > +	return unlikely(sk_rmem_alloc_get(sk) <= READ_ONCE(sk-
> > > >sk_rcvbuf)) ||
> > > +			__mptcp_check_fallback(mptcp_sk(sk));
> > The above should obviously be: 'likely(...)'
> > 
> > @Matttbe: please LMK if you prefer a repost or you could adjust
> > that
> > while applying to the export branch.
> No problem, I can adjust them when applying them (if there are no
> other
> big modifications required, but I guess no).

It seems you forgot to update this on the export branch.

Thanks,
-Geliang

> 
> Cheers,
> Matt