Netdev List
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>,
	Mat Martineau <martineau@kernel.org>,
	Geliang Tang <geliang@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev,
	linux-kernel@vger.kernel.org, Gang Yan <yangang@kylinos.cn>
Subject: Re: [PATCH net-next v2 2/5] mptcp: let the retrans scheduler do its job
Date: Mon, 3 Aug 2026 15:16:17 +0200	[thread overview]
Message-ID: <3e83bad9-833e-4946-b29f-cd006ecdc981@redhat.com> (raw)
In-Reply-To: <20260731-net-next-mptcp-oooq-pruning-v2-2-24838164fa21@kernel.org>

On 7/31/26 4:24 PM, Matthieu Baerts (NGI0) wrote:
> @@ -2851,14 +2849,88 @@ static void __mptcp_retrans(struct sock *sk)
>  	struct mptcp_sock *msk = mptcp_sk(sk);
>  	struct mptcp_subflow_context *subflow;
>  	struct mptcp_data_frag *dfrag;
> +	bool need_retrans;
> +	u64 retrans_seq;
>  	int err, len;
>  
> -	mptcp_clean_una_wakeup(sk);
> -
> -	/* first check ssk: need to kick "stale" logic */
> -	err = mptcp_sched_get_retrans(msk);
> +	mptcp_data_lock(sk);
> +	__mptcp_clean_una_wakeup(sk);
> +	retrans_seq = msk->snd_una;
>  	dfrag = mptcp_rtx_head(sk);
> -	if (!dfrag) {
> +	need_retrans = !!dfrag;
> +	mptcp_data_unlock(sk);
> +	if (!dfrag)
> +		goto check_data_fin;

Clashiko notes that the above will not kick the stale logic anymore when
all send data has been acked, and there is pending, unsent data.

That is intentional and safe: if no data is in-flight, we don't need
stale subflows detection.

> +
> +	for (;;) {
> +		bool already_retrans;
> +		u64 sent_seq;
> +
> +		/* The default scheduler will kick "stale" logic, that in
> +		 * turn can process incoming acks and clean the RTX queue;
> +		 * ensure that the current dfrag will still be around
> +		 * afterwards.
> +		 */
> +		get_page(dfrag->page);
> +		err = mptcp_sched_get_retrans(msk);

Clashiko noted that the above can cause bad accounting for the stale
logic. This needs to be fixed.

> +		if (err) {
> +			put_page(dfrag->page);
> +			break;
> +		}
> +
> +		/* Incoming acks can have moved retrans sequence after
> +		 * the current dfrag, if so try to start again from RTX head.
> +		 */
> +		mptcp_data_lock(sk);
> +		already_retrans = !before64(msk->snd_una, dfrag->data_seq +
> +					    dfrag->already_sent);
> +		put_page(dfrag->page);
> +		if (already_retrans) {
> +			__mptcp_clean_una_wakeup(sk);
> +			retrans_seq = msk->snd_una;
> +			dfrag = mptcp_rtx_head(sk);
> +			need_retrans = !!dfrag;
> +		} else if (after64(msk->snd_una, retrans_seq)) {
> +			retrans_seq = msk->snd_una;
> +		}
> +		mptcp_data_unlock(sk);
> +
> +		/* `already_sent` can be 0 for `dfrag` belonging to the RTX
> +		 *  queue due to __mptcp_retransmit_pending_data().
> +		 */
> +		if (!dfrag || !dfrag->already_sent)
> +			break;
> +
> +		/* Can fail only in case of fallback. */
> +		len = __mptcp_push_retrans(sk, dfrag, retrans_seq);
> +		if (len < 0)
> +			goto clear_scheduled;
> +
> +		retrans_seq += len;
> +		msk->bytes_retrans += len;
> +		dfrag->already_sent = max_t(u16, dfrag->already_sent,
> +					    retrans_seq - dfrag->data_seq);
> +
> +		/* With csum enabled retransmission can send new data. */
> +		sent_seq = dfrag->already_sent + dfrag->data_seq;
> +		if (after64(sent_seq, msk->snd_nxt))
> +			WRITE_ONCE(msk->snd_nxt, sent_seq);
> +
> +		/* Attempt the next fragment only if the current one is
> +		 * completely retransmitted.
> +		 */
> +		if (before64(retrans_seq, dfrag->data_seq + dfrag->data_len))
> +			break;
> +
> +		dfrag = list_is_last(&dfrag->list, &msk->rtx_queue) ?
> +				NULL : list_next_entry(dfrag, list);
> +		if (!dfrag)
> +			break;
> +	}
> +
> +	/* Attempt data-fin retransmission only when the RTX queue is empty. */
> +	if (!need_retrans) {

Clashiko noted that an error path could reach here with an outdated
`need_retrans` value. It needs to be fixed.

/P


  reply	other threads:[~2026-08-03 13:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 14:24 [PATCH net-next v2 0/5] mptcp: out-of-order queue pruning Matthieu Baerts (NGI0)
2026-07-31 14:24 ` [PATCH net-next v2 1/5] mptcp: move the retrans loop to a separate helper Matthieu Baerts (NGI0)
2026-07-31 14:24 ` [PATCH net-next v2 2/5] mptcp: let the retrans scheduler do its job Matthieu Baerts (NGI0)
2026-08-03 13:16   ` Paolo Abeni [this message]
2026-07-31 14:24 ` [PATCH net-next v2 3/5] mptcp: explicitly drop over memory limits Matthieu Baerts (NGI0)
2026-08-03 13:33   ` Paolo Abeni
2026-07-31 14:24 ` [PATCH net-next v2 4/5] mptcp: enforce hard limit on backlog flushing Matthieu Baerts (NGI0)
2026-07-31 14:24 ` [PATCH net-next v2 5/5] mptcp: implemented OoO queue pruning Matthieu Baerts (NGI0)
2026-08-03 13:42   ` Paolo Abeni

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=3e83bad9-833e-4946-b29f-cd006ecdc981@redhat.com \
    --to=pabeni@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=geliang@kernel.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=yangang@kylinos.cn \
    /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