public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Fernando Fernandez Mancera <fmancera@suse.de>
To: Krzysztof Kozlowski <krzk@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, dsahern@kernel.org
Subject: Re: [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs
Date: Mon, 9 Mar 2026 14:14:44 +0100	[thread overview]
Message-ID: <40011f00-b294-4832-b546-e3c40db8b59d@suse.de> (raw)
In-Reply-To: <4e3cd289-2b7a-4f64-99f6-05eb9d67c0fc@kernel.org>

On 3/9/26 2:02 PM, Krzysztof Kozlowski wrote:
> On 09/03/2026 13:58, Daniel Borkmann wrote:
>> On 3/9/26 1:43 PM, Krzysztof Kozlowski wrote:
>>> On 09/03/2026 12:38, Fernando Fernandez Mancera wrote:
>>>> On 3/9/26 11:22 AM, Krzysztof Kozlowski wrote:
>>>>> On 09/03/2026 03:19, Fernando Fernandez Mancera wrote:
>>>>>> Historically, the Linux kernel has supported compiling the IPv6 stack as
>>>>>> a loadable module. While this made sense in the early days of IPv6
>>>>>> adoption, modern deployments and distributions overwhelmingly either
>>>>>> build IPv6 directly into the kernel (CONFIG_IPV6=y) or disable it
>>>>>> entirely (CONFIG_IPV6=n). The modular IPv6 use-case provides little to
>>>>>> no practical benefit today.
>>>>>
>>>>> It does. We all use generic kernels, thus it is one configuration for
>>>>> all boards and some setups have IPv6 and some not. The ones without IPv6
>>>>> just don't use that module.
>>>>
>>>> While I understand this, I would like to clarify that IMHO IPv6 isn't a
>>>> secondary protocol and it is fundamental to modern networking. This is
>>>
>>> Not for end user devices. None of my devices - neither routers, nor
>>> embedded boards, nor mobile phone from 5G provider - receive IPv6
>>> address, thus for them it is not fundamental.
>>
>> If that is the case for them, then they should just CONFIG_IPV6=n.
> 
> That's not a question to me. Look what I wrote: "We all use generic
> kernels" - in a meaning of generic kernel, with generic defconfig built
> once serving every machine.
> 
>>
>>> I agree it is fundamental for your cloud machines and network backbone
>>> which you are targeting, but this patchset completely ignores other
>>> users calling their use-cases "little practical benefit"! Try running
>>> Amiga machine...
>>
>> Are you talking about [0]? That's legacy hardware and in this case just
> 
> Dunno what is legacy there...
> 
>> disable IPv6 altogether, why would you still prefer to have it as a module?
> 
> That's not a question to me - someone added it as a module now. The
> author here changes it to built-in.
> 
> 
>>
>>     [0] https://en.wikipedia.org/wiki/Amiga
>>
>>> There is no even bloatometer stats for these defconfigs so we can see
>>> the impact.
>>>
>>>> why I believe it should be built-in by default. Currently OpenWRT,
>>>> Debian ARM and others already ships the kernel with CONFIG_IPV6=y. I
>>>> know that Alpine and Yocto doesn't do that for arm64.
>>>
>>> Maybe there are other reasons why distro should not choose it as module
>>> (like module load calls on ipv6 packets) but that was not explained here.
>>>
>>> Arch Linux Rpi kernel on arm64 has IPV6=6 and the module itself is 650
>>> kB. That's noticeable for smaller arm64 boards.
>>>
>>> For arm it would be even more noticeable as some have 256 MB RAM like
>>> first Rpi.
>>
>> You are arguing that these will never be able to migrate to an IPv6 world
>> given their memory is too small?
> 
> No. I argue that they do not need IPv6 in many cases, thus use-case of
> IPV6=m is perfectly valid.
> 
> The entire discussion here started with "The modular IPv6 use-case
> provides little to no practical benefit today."
> 
> and this is clearly false. I brought you already few arguments of valid
> use case today.
> 
>>
>>>> I guess the most critical one here is Yocto but if the developer of the
>>>> embedded device is sure they won't use IPv6 at all, they should turn it off.
>>>>
>>>> At the same time, Alpine ships software that enable IPV6 and is
>>>> frequently loaded as a module. So the only remaining concern would be
>>>> the boot partition size. I don't really have a solution for that problem.
>>>>
>>>> I think that the infrastructure for allowing IPV6=m is bug-prone and it
>>>> impacts performance. Forcing the use of indirect function calls in core
>>>> networking, Netfilter or BPF datapaths seems like a heavy tax to me.
>>>>
>>>>> Also, with these generic kernels (so again all machines are using same
>>>>> ones, e.g. distro) users can easily blacklist the module.
>>>>
>>>> FWIW; users can still boot with kernel command line parameter
>>>> ipv6.disable=1 and then IPV6 will be administratively disabled.
>>>
>>> It's not the same. You enabled it on amiga_defconfig and do you
>>> understand what sort of machine is that? The newest have 16 MB RAM, many
>>> much less like 2 MB, and ipv6 module on m68k is 400 kB, so pretty
>>> significant change.
>>
>> If IPv6 is not relevant for amiga_defconfig presumably it should just be
>> set to CONFIG_IPV6=n?
> 
> It might be relevant to some, but this makes it relevant to everyone on
> Amiga.
> 
> There is a reason why kernel supports modules or do you suggest "modules
> provide little to no practical benefit today" and let's just have
> everything built-in or disabled.
> 

Right, maybe that is a too bold statement. Probably it could be 
rephrased to:

"While maintaining a modular IPv6 stack still offers footprint savings 
for specific setups, this benefit is outweighed by the architectural 
burden it imposes on the rest of the kernel."

I believe that having modules is useful. I just do not think it pays off 
here.


  reply	other threads:[~2026-03-09 13:14 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  2:19 [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 01/10 net-next] ipv6: convert CONFIG_IPV6 to built-in only and clean up Kconfigs Fernando Fernandez Mancera
2026-03-09 10:24   ` Krzysztof Kozlowski
2026-03-10 19:40     ` Kolbjørn Barmen
2026-03-10 19:58       ` Arnd Bergmann
2026-03-10 20:35         ` Sabrina Dubroca
2026-03-10 21:18         ` Bjørn Mork
2026-03-10 22:18           ` Arnd Bergmann
2026-03-11  8:21         ` Geert Uytterhoeven
2026-03-09  2:19 ` [PATCH 02/10 net-next] ipv6: replace IS_BUILTIN(CONFIG_IPV6) with IS_ENABLED(CONFIG_IPV6) Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 03/10 net-next] ipv6: remove dynamic ICMPv6 sender registration infrastructure Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 04/10 net-next] ipv6: prepare headers for ipv6_stub removal Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 05/10 net-next] drivers: net: drop ipv6_stub usage and use direct function calls Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 06/10 net-next] ipv4: " Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 07/10 net-next] net: convert remaining ipv6_stub users to " Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 08/10 net-next] bpf: remove ipv6_bpf_stub completely and use " Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 09/10 net-next] ipv6: remove ipv6_stub infrastructure completely Fernando Fernandez Mancera
2026-03-09  2:19 ` [PATCH 10/10 net-next] netfilter: remove nf_ipv6_ops and use direct function calls Fernando Fernandez Mancera
2026-03-09 10:22 ` [PATCH 00/10 net-next] Convert CONFIG_IPV6 to built-in and remove stubs Krzysztof Kozlowski
2026-03-09 10:26   ` Krzysztof Kozlowski
2026-03-09 23:18     ` Jakub Kicinski
2026-03-10 20:02       ` Krzysztof Kozlowski
2026-03-10 21:42         ` Jakub Kicinski
2026-03-10 22:15           ` Fernando Fernandez Mancera
2026-03-09 11:33   ` David Woodhouse
2026-03-09 11:38   ` Fernando Fernandez Mancera
2026-03-09 12:43     ` Krzysztof Kozlowski
2026-03-09 12:58       ` Daniel Borkmann
2026-03-09 13:02         ` Krzysztof Kozlowski
2026-03-09 13:14           ` Fernando Fernandez Mancera [this message]
2026-03-16 10:24           ` Lorenzo Stoakes (Oracle)
2026-03-16 10:33             ` Krzysztof Kozlowski
2026-03-16 10:50               ` Lorenzo Stoakes (Oracle)
2026-03-16 10:58                 ` Krzysztof Kozlowski
2026-03-16 11:10               ` Vlastimil Babka
2026-03-16 11:17                 ` Krzysztof Kozlowski
2026-03-09 13:07       ` Fernando Fernandez Mancera
2026-03-09 14:47 ` Jakub Kicinski
2026-03-09 15:10   ` Fernando Fernandez Mancera

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=40011f00-b294-4832-b546-e3c40db8b59d@suse.de \
    --to=fmancera@suse.de \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /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