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

Hi Geliang,

On 22/07/2026 12:01, Geliang Tang wrote:
> 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.

That's good if these patches are helping you, but I don't think Paolo is
going to work on a new version for these patches. The attached series --
mptcp: address stall under memory pressure -- has been applied, and it
didn't need these patches at the end.

I don't remember why these patches were not needed, but I guess you can
always cherry-pick them on your side, and modify them if needed.

Cheers,
Matt

> 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/

-- 
Sponsored by the NGI0 Core fund.