[RFC mptcp-next] mptcp: TX timestamping at the msk level

[RFC mptcp-next] mptcp: TX timestamping at the msk level

[David CARLIER]

Hi all,

After Paolo's comment on the MSG_ERRQUEUE series [1], I started looking
at msk-level TX timestamping. As far as I can see nobody is on it, so
I'd like to check the direction with you before writing code.

Today nothing arms tx_flags on the skbs built by mptcp_sendmsg_frag(),
so MPTCP data never gets a TX report. Roughly what I have in mind:

- keep the tsflags and the key (data seq of the last byte) on the
  dfrag, since the actual push happens after sendmsg returns;
- arm the subflow skb covering that byte, keeping its tskey in
  subflow seq space (tcp_fragment_tstamp() and tcp_ack_tstamp()
  rely on that);
- when forwarding SCHED/SND reports to the msk, rewrite ee_data to
  the msk key. I'm not sure yet how to do the mapping. The easiest
  option I see is a small per-subflow list of (subflow seq, data seq)
  pairs for armed bytes;
- emit ACK reports from __mptcp_clean_una() on DATA_ACK rather than
  forwarding subflow ACKs;
- seed the msk sk_tskey for OPT_ID the way TCP does.

The one I went back and forth on is reinjection: the same bytes can
leave on several subflows. Plain TCP already reports again on
retransmit, so reporting each transmission seems acceptable to me, but
I'd like your opinion.

Geliang, your MSG_ZEROCOPY series [2] touches the same spots (dfrag
layout, coalescing in mptcp_sendmsg_frag()). I'm happy to build on t
of it. Do you know if it's still moving?

Cheers

[1] https://lore.kernel.org/mptcp/d6cdbc83-86a6-4c2a-ad99-29cdb83566
[2] https://lore.kernel.org/mptcp/32bac661bcae143f7e63905dfb781c98e95cdde5.1784260668.git.tanggeliang@kylinos.cn/

Re: [RFC mptcp-next] mptcp: TX timestamping at the msk level

[Geliang Tang]

Hi David,

On Wed, 2026-09-23 at 04:27 +0100, David CARLIER wrote:
> Hi all,
> 
> After Paolo's comment on the MSG_ERRQUEUE series [1], I started
> looking
> at msk-level TX timestamping. As far as I can see nobody is on it, so
> I'd like to check the direction with you before writing code.
> 
> Today nothing arms tx_flags on the skbs built by
> mptcp_sendmsg_frag(),
> so MPTCP data never gets a TX report. Roughly what I have in mind:
> 
> - keep the tsflags and the key (data seq of the last byte) on the
>   dfrag, since the actual push happens after sendmsg returns;
> - arm the subflow skb covering that byte, keeping its tskey in
>   subflow seq space (tcp_fragment_tstamp() and tcp_ack_tstamp()
>   rely on that);
> - when forwarding SCHED/SND reports to the msk, rewrite ee_data to
>   the msk key. I'm not sure yet how to do the mapping. The easiest
>   option I see is a small per-subflow list of (subflow seq, data seq)
>   pairs for armed bytes;
> - emit ACK reports from __mptcp_clean_una() on DATA_ACK rather than
>   forwarding subflow ACKs;
> - seed the msk sk_tskey for OPT_ID the way TCP does.
> 
> The one I went back and forth on is reinjection: the same bytes can
> leave on several subflows. Plain TCP already reports again on
> retransmit, so reporting each transmission seems acceptable to me,
> but
> I'd like your opinion.
> 
> Geliang, your MSG_ZEROCOPY series [2] touches the same spots (dfrag
> layout, coalescing in mptcp_sendmsg_frag()). I'm happy to build on t
> of it. Do you know if it's still moving?

My MSG_ZEROCOPY series is still moving forward, but it will wait for a
while, since there are other series to handle first.

I found that I have a local patch "preserve the rx timestamp when
coalescing skbs", which I added while debugging some feature earlier.
It might be useful, and I'll include it in the next version of the
MSG_ZEROCOPY series too. Something like:

@@ -178,6 +178,13 @@ static bool __mptcp_try_coalesce(struct sock *sk,

            MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
            to->len, MPTCP_SKB_CB(from)->end_seq);
   MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
+
+  if (MPTCP_SKB_CB(from)->has_rxtstamp) {
+          MPTCP_SKB_CB(to)->has_rxtstamp = true;
+          to->tstamp = from->tstamp;
+          skb_hwtstamps(to)->hwtstamp = skb_hwtstamps(from)->hwtstamp;
+  }
+
   return true;
 }

Thanks,
-Geliang

> 
> Cheers
> 
> [1] https://lore.kernel.org/mptcp/d6cdbc83-86a6-4c2a-ad99-29cdb83566
> [2]
> https://lore.kernel.org/mptcp/32bac661bcae143f7e63905dfb781c98e95cdde5.1784260668.git.tanggeliang@kylinos.cn/

Re: [RFC mptcp-next] mptcp: TX timestamping at the msk level

[David CARLIER]

Hi Geliang,

On Wed, 30 Sept 2026 at 05:09, Geliang Tang <geliang@kernel.org> wrote:
>
> Hi David,
>
> On Wed, 2026-09-23 at 04:27 +0100, David CARLIER wrote:
> > Hi all,
> >
> > After Paolo's comment on the MSG_ERRQUEUE series [1], I started
> > looking
> > at msk-level TX timestamping. As far as I can see nobody is on it, so
> > I'd like to check the direction with you before writing code.
> >
> > Today nothing arms tx_flags on the skbs built by
> > mptcp_sendmsg_frag(),
> > so MPTCP data never gets a TX report. Roughly what I have in mind:
> >
> > - keep the tsflags and the key (data seq of the last byte) on the
> >   dfrag, since the actual push happens after sendmsg returns;
> > - arm the subflow skb covering that byte, keeping its tskey in
> >   subflow seq space (tcp_fragment_tstamp() and tcp_ack_tstamp()
> >   rely on that);
> > - when forwarding SCHED/SND reports to the msk, rewrite ee_data to
> >   the msk key. I'm not sure yet how to do the mapping. The easiest
> >   option I see is a small per-subflow list of (subflow seq, data seq)
> >   pairs for armed bytes;
> > - emit ACK reports from __mptcp_clean_una() on DATA_ACK rather than
> >   forwarding subflow ACKs;
> > - seed the msk sk_tskey for OPT_ID the way TCP does.
> >
> > The one I went back and forth on is reinjection: the same bytes can
> > leave on several subflows. Plain TCP already reports again on
> > retransmit, so reporting each transmission seems acceptable to me,
> > but
> > I'd like your opinion.
> >
> > Geliang, your MSG_ZEROCOPY series [2] touches the same spots (dfrag
> > layout, coalescing in mptcp_sendmsg_frag()). I'm happy to build on t
> > of it. Do you know if it's still moving?
>
> My MSG_ZEROCOPY series is still moving forward, but it will wait for a
> while, since there are other series to handle first.
>
> I found that I have a local patch "preserve the rx timestamp when
> coalescing skbs", which I added while debugging some feature earlier.
> It might be useful, and I'll include it in the next version of the
> MSG_ZEROCOPY series too. Something like:
>
> @@ -178,6 +178,13 @@ static bool __mptcp_try_coalesce(struct sock *sk,
>
>             MPTCP_SKB_CB(from)->map_seq, MPTCP_SKB_CB(to)->map_seq,
>             to->len, MPTCP_SKB_CB(from)->end_seq);
>    MPTCP_SKB_CB(to)->end_seq = MPTCP_SKB_CB(from)->end_seq;
> +
> +  if (MPTCP_SKB_CB(from)->has_rxtstamp) {
> +          MPTCP_SKB_CB(to)->has_rxtstamp = true;
> +          to->tstamp = from->tstamp;
> +          skb_hwtstamps(to)->hwtstamp = skb_hwtstamps(from)->hwtstamp;
> +  }
> +
>    return true;
>  }
>
> Thanks,
> -Geliang

Ah nice looking forward to it !
>
> >
> > Cheers
> >
> > [1] https://lore.kernel.org/mptcp/d6cdbc83-86a6-4c2a-ad99-29cdb83566
> > [2]
> > https://lore.kernel.org/mptcp/32bac661bcae143f7e63905dfb781c98e95cdde5.1784260668.git.tanggeliang@kylinos.cn/