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/