public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Fernando Fernandez Mancera <fmancera@suse.de>, 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 13:43:41 +0100	[thread overview]
Message-ID: <6c005900-3461-4e3c-a396-b2984735af9b@kernel.org> (raw)
In-Reply-To: <cd87ed46-b774-4896-b25e-4806eec9e0b3@suse.de>

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.

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...

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.

> 
> 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.

Best regards,
Krzysztof

  reply	other threads:[~2026-03-09 12:43 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 [this message]
2026-03-09 12:58       ` Daniel Borkmann
2026-03-09 13:02         ` Krzysztof Kozlowski
2026-03-09 13:14           ` Fernando Fernandez Mancera
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=6c005900-3461-4e3c-a396-b2984735af9b@kernel.org \
    --to=krzk@kernel.org \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=fmancera@suse.de \
    --cc=horms@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