Re: [PATCH net-next v8 0/6] move CAN skb headroom content to skb extensions

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 05.02.26 11:54, Paolo Abeni wrote:
> On 2/3/26 8:19 PM, Oliver Hartkopp wrote:
>> When CONFIG_CAN is enabled the skbuff_ext_cache element would increase
>> in size by 8 bytes (sizeof(struct can_skb_ext)) on my machine (see
>> pahole output below).
>>
>> So when everything is enabled it would be
>>
>> CONFIG_SKB_EXTENSIONS
>> 8  bytes sizeof(struct skb_ext)
>> CONFIG_BRIDGE_NETFILTER
>> 32 bytes sizeof(struct nf_bridge_info)
>> CONFIG_XFRM
>> 88 bytes sizeof(struct sec_path)
>> CONFIG_NET_TC_SKB_EXT
>> 16 bytes sizeof(struct tc_skb_ext)
>> CONFIG_MPTCP
>> 32 bytes sizeof(struct mptcp_ext)
>> CONFIG_MCTP_FLOWS
>> 8  bytes sizeof(struct mctp_flow)
>> CONFIG_INET_PSP
>> 8  bytes sizeof(struct psp_skb_ext)
>> CONFIG_CAN
>> 8  bytes sizeof(struct can_skb_ext)
>> ---------
>> 200 bytes total skbuff_ext_cache element size
>> (255 * 8 = 2040 bytes max space for skb extension users).
>>
>> Does this answer your question?
> 
> Yes, thank you for the collaboration!
> 
> I think there is mistake above: sizeof(struct skb_ext) should be 16 when
> more than 3 skb extensions are enabled.

Oh, yes. You are right!

struct skb_ext {
         refcount_t                 refcnt;               /*     0     4 */
         u8                         offset[7];            /*     4     7 */
         u8                         chunks;               /*    11     1 */

         /* XXX 4 bytes hole, try to pack */

         char                       data[] 
__attribute__((__aligned__(8))); /*    16     0 */

         /* size: 16, cachelines: 1, members: 4 */
         /* sum members: 12, holes: 1, sum holes: 4 */
         /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
         /* last cacheline: 16 bytes */
} __attribute__((__aligned__(8)));

After I enabled all kernel configs that would increase the skb 
extensions I just copied the missing pahole structs into the mail - not 
looking for the struct skb_ext again ...

> that means that the total extension size already exceeds the 3
> cachelines (192 bytes) boundary when all extensions are enabled and
> adding the CAN one should not cause any regressions is such scenario.
> 
> Note that the "all skb extensions enabled" is possibly/likely NOT the
> most common/relevant one, but I think there is some space we can squeeze
> elsewhere if needed.

Right.

Many thanks!
Oliver