All of lore.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: 29+ 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-29  8:48           ` b4 prep --auto-to-cc fails with 'NoneType' object is not subscriptable Marc Kleine-Budde
2026-01-29 10:09             ` Oliver Hartkopp
2026-01-29 10:19               ` Marc Kleine-Budde
2026-01-29 10:31                 ` Oliver Hartkopp
2026-01-29 12:35                   ` Marc Kleine-Budde
2026-01-29 14:22                     ` Oliver Hartkopp
2026-01-29 15:28                       ` Marc Kleine-Budde
2026-01-29 15:33                         ` Oliver Hartkopp
2026-01-28 11:35   ` [net-next 0/6] move CAN skb headroom content to skb extensions 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.