Re: [mptcp-next,v5,07/12] mptcp: sync mptcp skb cb layout with tcp one

Geliang Tang <[email protected]> Wed, 22 Jul 2026 18:01:04 +0800
Newsgroups dev.linux.lists.mptcp
Message-ID <[email protected]>
Hi Paolo,

Patches 6 and 7 turn out to be very helpful for simplifying my MPTCP KTLS
support implementation.

To let KTLS obtain an skb's sequence number, I had defined a get_skb_seq
operation in [1]. The TCP implementation was:

static u32 tcp_get_skb_seq(struct sk_buff *skb)
{
      return TCP_SKB_CB(skb)->seq;
}

and the MPTCP one was:

static u32 mptcp_get_skb_seq(struct sk_buff *skb)
{
      return MPTCP_SKB_CB(skb)->map_seq - MPTCP_SKB_CB(skb)->offset;
}

After Patch 6 removes the CB offset field, the MPTCP implementation collapses
to simply:

      return MPTCP_SKB_CB(skb)->map_seq;

And after Patch 7 changes map_seq from u64 to u32, the get_skb_seq operation
is no longer needed at all. The two control blocks now expose the sequence
number identically (same type, same offset), so I can define a single
TLS_SKB_CB accessor that works for both TCP and MPTCP without any
per-protocol dispatch:

struct tls_skb_cb {
      u32 seq;
};

#define TLS_SKB_CB(__skb)     ((struct tls_skb_cb *)&((__skb)->cb[0]))

static_assert(offsetof(struct tcp_skb_cb, seq) == 0);
static_assert(offsetof(struct mptcp_skb_cb, map_seq) == 0);

The static_asserts guarantee at compile time that both layouts keep the
sequence number at offset 0, so TLS_SKB_CB(skb)->seq reads the correct
value regardless of the underlying protocol.

I have reworked the entire MPTCP KTLS series on top of patches 4-8 of this
series. Building on the removal of the CB offset field, I also added a patch
that trims the duplicated skb head at receive enqueue. With that in place,
KTLS can retrieve the record header via skb_copy_bits() directly, so there
is no longer any need for a dedicated MPTCP helper like the
mptcp_skb_get_header() I introduced in [2].

Looking forward to your next version of patches 4-8. Happy to help out with
them if that's useful.

Thanks,
-Geliang

[1] https://patchwork.kernel.org/project/mptcp/patch/eacfe3e5929c07d35d08cab6663c61d40fac8649.1782123118.git.tanggeliang@kylinos.cn/
[2] https://patchwork.kernel.org/project/mptcp/patch/447fc4384ba0d4b0f78c452239dbb3e87e021578.1782123118.git.tanggeliang@kylinos.cn/