Re: [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one

[Alexander H Duyck <alexander.duyck@gmail.com>]

On Thu, 2022-12-15 at 11:24 +0800, 梁礼学 wrote:
> The module parameter method does bring some inconvenience to the user, 
> especially the parameter needs to be specified when the module is loaded. 
> But as alexander said, if the net device is not successfully registered, 
> the user has no chance to modify the invalid MAC address in the current EEPROM. 
> At present, the read/write of EEPROM is bundled with the net driver. 
> I am not sure if there is any other way to complete the modification of EEPROM 
> independently of the network driver;
> 
> 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 function of the device, 
> this should not affect the registration of the device;
> Can the invalid MAC be judged in the up stage of the network device? 
> In this way, the net driver can continue to be loaded successfully, 
> and the MAC can be changed using ethtool, and it will not increase the difficulty of debugging for users.
> 
> 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.