Re: [PATCH net-next v8 0/6] move CAN skb headroom content to skb extensions
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: 2026-02-05 12:37:54
Also in:
linux-can, lkml
On 05.02.26 11:54, Paolo Abeni wrote:
On 2/3/26 8:19 PM, Oliver Hartkopp wrote:quoted
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