Re: [PATCH RESENT v7 mptcp-next 4/4] mptcp: leverage the backlog for RX packet processing

[Mat Martineau <martineau@kernel.org>]

On Mon, 3 Nov 2025, Paolo Abeni wrote:

> On 11/1/25 1:04 AM, Mat Martineau wrote:
>> On Mon, 27 Oct 2025, Paolo Abeni wrote:
>>> @@ -3573,6 +3586,8 @@ static void mptcp_release_cb(struct sock *sk)
>>>
>>> 		cond_resched();
>>> 		spin_lock_bh(&sk->sk_lock.slock);
>>> +		if (spool_bl)
>>> +			mptcp_backlog_spooled(sk, moved, &skbs);
>>
>> Hi Paolo -
>>
>> Given the discussion in v5, to address the "wild producer" scenario this
>> loop can keep track of total_moved and exit the loop when that gets too
>> large.
>>
>> The question is what the total limit would be - available rcvbuf when
>> entering the loop, or some multiple of that?
>
> I spent a lot of time around that choice. Limiting the loop here is
> quite tricky. Stopping the loop after sk_rcvbuf bytes causes mptcp-level
> OoO and adds additional complexity to the code (as the receiver will
> need to check the backlog even when the receive queue is not empty.
>
> Note that the code proposed in this series is as robust as the current
> (i.e. release_cb() can already be bothered by a wild producer in exactly
> the same way).
>
> I propose to decouple the wild producer problem solution from these patches.

Sounds reasonable to me. After the v5 thread, wanted to be sure I was 
clearly understanding the tradeoffs. Thanks for the details!

- Mat