MPTCP Linux Development
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Mat Martineau <martineau@kernel.org>
Cc: mptcp@lists.linux.dev, geliang@kernel.org
Subject: Re: [PATCH RESENT v7 mptcp-next 4/4] mptcp: leverage the backlog for RX packet processing
Date: Mon, 3 Nov 2025 17:23:16 +0100	[thread overview]
Message-ID: <bf160603-cfb4-4945-81d2-c958043078cf@redhat.com> (raw)
In-Reply-To: <6fb0d5aa-8140-505d-c40f-1dc40fff352f@kernel.org>

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.

/P


  reply	other threads:[~2025-11-03 16:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-27 14:57 [PATCH RESENT v7 mptcp-next 0/4] mptcp: introduce backlog processing Paolo Abeni
2025-10-27 14:57 ` [PATCH RESENT v7 mptcp-next 1/4] mptcp: handle first subflow closing consistently Paolo Abeni
2025-10-27 14:58 ` [PATCH RESENT v7 mptcp-next 2/4] mptcp: borrow forward memory from subflow Paolo Abeni
2025-10-31 22:44   ` Mat Martineau
2025-11-03 16:26     ` Paolo Abeni
2025-10-27 14:58 ` [PATCH RESENT v7 mptcp-next 3/4] mptcp: introduce mptcp-level backlog Paolo Abeni
2025-10-27 14:58 ` [PATCH RESENT v7 mptcp-next 4/4] mptcp: leverage the backlog for RX packet processing Paolo Abeni
2025-11-01  0:04   ` Mat Martineau
2025-11-03 16:23     ` Paolo Abeni [this message]
2025-11-04 22:32       ` Mat Martineau
2025-10-27 16:13 ` [PATCH RESENT v7 mptcp-next 0/4] mptcp: introduce backlog processing MPTCP CI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf160603-cfb4-4945-81d2-c958043078cf@redhat.com \
    --to=pabeni@redhat.com \
    --cc=geliang@kernel.org \
    --cc=martineau@kernel.org \
    --cc=mptcp@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox