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
next prev parent 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