Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3bc9c4dab64860fde7405fd589375f0ae087afe9.camel@gmail.com>
Subject: Re: [PATCH v7] igb: Assign random MAC address instead of fail in
 case of invalid one
From:   Alexander H Duyck <alexander.duyck@gmail.com>
To:     =?UTF-8?Q?=E6=A2=81=E7=A4=BC=E5=AD=A6?= <lianglixuehao@126.com>
Cc:     Heiner Kallweit <hkallweit1@gmail.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Leon Romanovsky <leon@kernel.org>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        linux-kernel@vger.kernel.org,
        Jesse Brandeburg <jesse.brandeburg@intel.com>,
        David Miller <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Netdev <netdev@vger.kernel.org>
Date:   Thu, 15 Dec 2022 07:49:59 -0800
In-Reply-To: <2D8AD99A-E29B-40CC-AFEC-3D9D4AC80C14@126.com>
References: <20221213074726.51756-1-lianglixuehao@126.com>
         <Y5l5pUKBW9DvHJAW@unreal> <20221214085106.42a88df1@kernel.org>
         <Y5obql8TVeYEsRw8@unreal> <20221214125016.5a23c32a@kernel.org>
         <4576ee79-1040-1998-6d91-7ef836ae123b@gmail.com>
         <CAKgT0UdZUmFD8qYdF6k47ZmRgB0jS-graOYgB5Se+y+4fKqW8w@mail.gmail.com>
         <2D8AD99A-E29B-40CC-AFEC-3D9D4AC80C14@126.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2022-12-15 at 11:24 +0800, =E6=A2=81=E7=A4=BC=E5=AD=A6 wrote:
> The module parameter method does bring some inconvenience to the user,=
=20
> especially the parameter needs to be specified when the module is loaded.=
=20
> But as alexander said, if the net device is not successfully registered,=
=20
> the user has no chance to modify the invalid MAC address in the current E=
EPROM.=20
> At present, the read/write of EEPROM is bundled with the net driver.=20
> I am not sure if there is any other way to complete the modification of E=
EPROM=20
> independently of the network driver;
>=20
> Is it necessary to bind the registration of net device to the judgment of=
 invalid MAC?
> I personally think that MAC configuration is not the capability or functi=
on of the device,=20
> this should not affect the registration of the device;
> Can the invalid MAC be judged in the up stage of the network device?=20
> In this way, the net driver can continue to be loaded successfully,=20
> and the MAC can be changed using ethtool, and it will not increase the di=
fficulty of debugging for users.
>=20
> Thanks

The problem is that the decision all depends on use case. For a small
embedded device or desktop system it probably doesn't care as it will
always just default to DHCP most likely anyway so it doesn't really
care about maintaining a static MAC configuration.

However the igb device covers a range of products including workstation
and some server. The issue is that changing the MAC address on server
setups can trigger significant issues depending on the setup as things
like static IP reservations can be lost due to either a static DHCP
reservation or sysconfig potentially being lost. I know on older redhat
systems random MACs would lead to a buildup up sysconfig files as it
would generate a new one every time the MAC changed. It is one of the
reasons why Intel stopped using random MAC on VFs if I recall
correctly.

Lastly one thing that occurs to me is that there is support for
providing a MAC address via eth_platform_get_mac_address() as some of
the smaller embedded parts have an option to run without an EEPROM. I
wonder if there isn't a way to work around this by providing a
devicetree overlay on problematic systems.