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

Hi Paolo,

On Mon, 2026-07-27 at 12:04 +0200, Paolo Abeni wrote:
> 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.

Thanks for your reply. I just did a little cleanup on patches 4-7 and
sent them together with my two patches to the mailing list, under the
name "Reduce the differences between TCP and MPTCP for TLS usage".

Thanks,
-Geliang

> 
> /P