Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d
MIME-Version: 1.0
Message-Id: <4ed81222-9409-4c9b-bd29-dbaf4275984f@app.fastmail.com>
In-Reply-To: <20231003154326.213e9c81@kernel.org>
References: <20230925155858.651425-1-arnd@kernel.org>
 <1430f3d3-4e84-b0ec-acd9-8a51db178f73@intel.com>
 <20231003154326.213e9c81@kernel.org>
Date:   Wed, 04 Oct 2023 10:25:03 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Jakub Kicinski" <kuba@kernel.org>,
        "Anthony L Nguyen" <anthony.l.nguyen@intel.com>
Cc:     "Arnd Bergmann" <arnd@kernel.org>,
        "Jesse Brandeburg" <jesse.brandeburg@intel.com>,
        "Lobakin, Alexandr" <alexandr.lobakin@intel.com>,
        "David S . Miller" <davem@davemloft.net>,
        "Eric Dumazet" <edumazet@google.com>,
        "Paolo Abeni" <pabeni@redhat.com>,
        "Alan Brady" <alan.brady@intel.com>,
        "Sridhar Samudrala" <sridhar.samudrala@intel.com>,
        "Willem de Bruijn" <willemb@google.com>,
        "Phani Burra" <phani.r.burra@intel.com>,
        "Joshua A Hay" <joshua.a.hay@intel.com>,
        "Pavan Kumar Linga" <pavan.kumar.linga@intel.com>,
        "Madhu Chittim" <madhu.chittim@intel.com>,
        "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>,
        Netdev <netdev@vger.kernel.org>, linux-kernel@vger.kernel.org,
        "Alexander Lobakin" <aleksander.lobakin@intel.com>
Subject: Re: [PATCH] idpf: fix building without IPv4
Content-Type: text/plain
Precedence: bulk

On Wed, Oct 4, 2023, at 00:43, Jakub Kicinski wrote:
> On Mon, 25 Sep 2023 10:05:03 -0700 Tony Nguyen wrote:
>> Also, a pending patch for this [1], however, this does look a bit more 
>> efficient. Adding Olek as he's author on the other patch.
>> 
>> netdev maintainers,
>> 
>> If this is the version that does get picked up, did you want to take it 
>> directly to close out the compile issues?
>
> Sorry for the delays. Should we not add a !INET static inline wrapper
> for tcp_gro_complete()? Seems a bit backwards to me to make drivers
> suffer and think about such a preposterous config :S
>
> $ git grep tcp_gro_complete -- drivers/
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:        tcp_gro_complete(skb);
> drivers/net/ethernet/broadcom/bnxt/bnxt.c:              tcp_gro_complete(skb);
> drivers/net/ethernet/intel/idpf/idpf_txrx.c:    tcp_gro_complete(skb);
> drivers/net/ethernet/qlogic/qede/qede_fp.c:     tcp_gro_complete(skb);
>
> We have 4 drivers which need ifdefs already and the number will only
> grow with GRO-HW spreading.

That sounds good to me, but it's better if someone that understands
this code patch better than me writes the stub helpers, to ensure
all callers have sensible behavior in that configuration.

I also had a brief look at who might be using kernels without CONFIG_INET.
In the kernel source tree, there are 19 defconfig files that completely
enable CONFIG_NET, which means that both INET and ETHERNET are always
turned off as well.

There are four configs that enable CONFIG_NET but not CONFIG_INET:

arch/arm/configs/spear3xx_defconfig
arch/arm/configs/spear6xx_defconfig
arch/m68k/configs/virt_defconfig
arch/s390/configs/zfcpdump_defconfig

I'm confident that the two arm configs are a mistake, as these are
regular embedded SoCs with on-chip ethernet that is enabled in
the config but almost certainly has no other use. The virt defconfig
lost CONFIG_INET after commit d7385ba13771 ("9p: Remove INET
dependency") added an 'imply INET'. This sounds like a bad idea,
since it messes up the 'defconfig' logic when a leaf driver enables
an entire subsystem.

The s390 zfcpdump defconfig looks like a legitimate case for
disabling INET, but it's not that size constrained and it might
not actually need CONFIG_NET either.

So overall, it seems there is no real need to support CONFIG_NET=y
with CONFIG_INET=n and we could just make them be the same and
avoid bugs like this. In theory we could also go the opposite way
and try to make INET a tristate symbol that can live in a loadable
module like all other network protocols. This would be nice
conceptually and for smaller vmlinux files (some systems are
much more limited in the size of their boot partition than their
RAM and rootfs), but would clearly cause way more build failures.

      Arnd