public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-can@vger.kernel.org
Subject: Re: [net-next 0/6] move CAN skb headroom content to skb extensions
Date: Wed, 28 Jan 2026 14:18:33 +0100	[thread overview]
Message-ID: <aXoMqaA7b2CqJZNA@strlen.de> (raw)
In-Reply-To: <4909066f-cf9c-49ac-b02f-d2e16908bbd9@hartkopp.net>

Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> > When the first extensions were added all of them could be enabled
> > at same time, but I think that has changed.
> 
> IMO we do not need to 'union' extensions as long as automatic enum 
> calculation does it job with the enabled Kconfig options.
>
> My only concern would be distribution kernels that have an all-yes 
> config policy ;-)

Well, thats the norm, no?  Allmodconfig.
So we have two issues:
1. Turn active_extensions in sk_buff into u16
2. Growing memory usage of the skb_ext blob.

No need to add this 'union' now of course, but I think its something
that should be kept in mind: originally, all extensions could be
turned on for the same skb, but it looks like we now have mutually
exclusive ones.

> With my patch set the enum would now look like this:
> 
> #ifdef CONFIG_SKB_EXTENSIONS
> enum skb_ext_id {
> #if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
>          SKB_EXT_BRIDGE_NF,
> #endif
> #ifdef CONFIG_XFRM
>          SKB_EXT_SEC_PATH,
> #endif
> #if IS_ENABLED(CONFIG_NET_TC_SKB_EXT)
>          TC_SKB_EXT,
> #endif
> #if IS_ENABLED(CONFIG_MPTCP)
>          SKB_EXT_MPTCP,
> #endif
> #if IS_ENABLED(CONFIG_MCTP_FLOWS)
>          SKB_EXT_MCTP,
> #endif
> #if IS_ENABLED(CONFIG_INET_PSP)
>          SKB_EXT_PSP,
> #endif
> #if IS_ENABLED(CONFIG_CAN)
>          SKB_EXT_CAN,
> #endif
>          SKB_EXT_NUM, /* must be last */
> };
> 
> => SKB_EXT_NUM is then 7
> 
> When we (correctly) add another extension, SKB_EXT_NUM would become 8 
> which is still fine IMO. But then the BUILD_BUG_ON check in 
> skb_extensions_init() would need the below fix, right?
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 648c20e19038..609851d70173 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5156,11 +5156,11 @@ static __always_inline unsigned int 
> skb_ext_total_length(void)
>          return l;
>   }
> 
>   static void skb_extensions_init(void)
>   {
> -       BUILD_BUG_ON(SKB_EXT_NUM >= 8);
> +       BUILD_BUG_ON(SKB_EXT_NUM > 8);

True, the last valid extension id can't be 8, but
SKB_EXT_NUM could be.

> Should I send a proper patch?

You can, otoh I think we should have consensus on what
to do when the 8th extension is added, do we just s/u8/u16' and
eat the growing memory cost for the skb_ext growth, or do we go
to a drawing board and figure out how to best merge mutually exclusive
extensions to save space?

  reply	other threads:[~2026-01-28 13:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-25 20:15 [net-next 0/6] move CAN skb headroom content to skb extensions Oliver Hartkopp
2026-01-25 20:15 ` [net-next 1/6] can: use skb hash instead of private variable in headroom Oliver Hartkopp
2026-01-28  1:45   ` Jakub Kicinski
2026-01-25 20:15 ` [net-next 2/6] can: add CAN skb extension infrastructure Oliver Hartkopp
2026-01-25 20:15 ` [net-next 3/6] can: move ifindex to CAN skb extensions Oliver Hartkopp
2026-01-25 20:15 ` [net-next 4/6] can: move frame_len " Oliver Hartkopp
2026-01-25 20:16 ` [net-next 5/6] can: remove private CAN skb headroom infrastructure Oliver Hartkopp
2026-01-28  1:49 ` [net-next 0/6] move CAN skb headroom content to skb extensions Jakub Kicinski
2026-01-28  8:42   ` Oliver Hartkopp
2026-01-28  9:07     ` Marc Kleine-Budde
2026-01-28 10:04       ` Marc Kleine-Budde
2026-01-28 10:17         ` Oliver Hartkopp
2026-01-29  6:44       ` Marc Kleine-Budde
2026-01-29  7:49         ` Oliver Hartkopp
2026-01-29  8:42           ` Marc Kleine-Budde
2026-01-28 11:35   ` Florian Westphal
2026-01-28 12:52     ` Oliver Hartkopp
2026-01-28 13:18       ` Florian Westphal [this message]
2026-01-28 16:14         ` Oliver Hartkopp
2026-01-28 16:25           ` Florian Westphal
2026-01-28 16:34             ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aXoMqaA7b2CqJZNA@strlen.de \
    --to=fw@strlen.de \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox