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

On 7/24/26 12:25 PM, Matthieu Baerts wrote:
> 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.
The goal behind that patches was to reuse for mptcp the tcp ofo queue
pruning helper. Discussion with Eric pointed out that ofo queue pruning
is actually a bad thing, so I just omitted that for mptcp and dropped
the pre-req patches.

Patch 6 could have some merit on its own, as IIRC reduced the
conditionals in fast-path and cleaned-up the code a bit.

/P