[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <883ee734-b9bd-42be-b072-23640fd34fdb@intel.com>
Date: Tue, 29 Apr 2025 14:40:22 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Andrew Lunn <andrew@...n.ch>, David Howells <dhowells@...hat.com>
CC: Jedrzej Jagielski <jedrzej.jagielski@...el.com>, Przemek Kitszel
<przemyslaw.kitszel@...el.com>, Tony Nguyen <anthony.l.nguyen@...el.com>,
Paulo Abeni <pabeni@...hat.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: Is it possible to undo the ixgbe device name change?
On 4/25/2025 5:11 AM, Andrew Lunn wrote:
> On Fri, Apr 25, 2025 at 09:58:35AM +0100, David Howells wrote:
>> Andrew Lunn <andrew@...n.ch> wrote:
>>
>>> Are you sure this patch is directly responsible? Looking at the patch
>>
>> I bisected it to that commit. Userspace didn't change.
>
> As Jakub pointed out, the kernel is now providing additional
> information to user space, via devlink. That causes systemd's 'stable'
> names to change. The naming rules are documented somewhere.
>
>>> Notice the context, not the change. The interface is being called
>>> eth%d, which is normal. The kernel will replace the %d with a unique
>>> number. So the kernel will call it eth42 or something. You should see
>>> this in dmesg.
>>
>> Something like this?
>>
>> ... systemd-udevd[2215]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>> ... kernel: ixgbe 0000:01:00.0 enp1s0: renamed from eth0
>>
>> or:
>>
>> ... systemd-udevd[2568]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>> ... kernel: ixgbe 0000:01:00.0 enp1s0np0: renamed from eth0
>>
>> I presume the kernel message saying that the renaming happened is triggered by
>> systemd-udevd?
>
> systemd-udevd is not really triggering it. It is providing the new
> name and asking the kernel to change the name. To some extent, you can
> think of this as policy. The kernel tries to avoid policy, it leaves
> it up to user space. The kernel provides a default name for the
> interface, but it is policy in user space which gives it its final
> name.
>
> Andrew
>
systemd has the systemd.net-naming-scheme file and it has this to say:
> LIMITING THE USE OF SPECIFIC SYSFS ATTRIBUTES
> When creating names for network cards, some naming schemes use data from
> sysfs populated by the kernel. This means that although a specific naming
> scheme in udev is picked, the network card's name can still change when a
> new kernel version adds a new sysfs attribute. For example if kernel starts
> setting the phys_port_name, udev will append the "nphys_port_name" suffix to
> the device name.
>
> ID_NET_NAME_ALLOW=BOOL
> This udev property sets a fallback policy for reading a sysfs attribute. If
> set to 0 udev will not read any sysfs attribute by default, unless it is
> explicitly allowlisted, see below. If set to 1 udev can use any sysfs
> attribute unless it is explicitly forbidden. The default value is 1.
>
> Added in version 256.
>
> ID_NET_NAME_ALLOW_sysfsattr=BOOL
> This udev property explicitly states if udev shall use the specified
> sysfsattr, when composing the device name.
>
> Added in version 256.
>
> With these options, users can set an allowlist or denylist for sysfs
> attributes. To create an allowlist, the user needs to set
> ID_NET_NAME_ALLOW=0 for the device and then list the allowed attributes with
> the ID_NET_NAME_ALLOW_sysfsattr=1 options. In case of a denylist, the user
> needs to provide the list of denied attributes with the
> ID_NET_NAME_ALLOW_sysfsattr=0 options.
>
If you want to stop including the "np<N>" to the device names, I believe
you can set the ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0 via udev properties.
>From what I can tell searching online, this can be done by setting an
appropriate entry in /etc/udev/hwdb.d/ .. i.e. adding this file:
/etc/udev/hwdb.d/50-net-naming-disable-phys-port-name.hwdb
net:naming:*
ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0
after adding this file, you also need to update the hardware database with
$ systemd-hwdb update
>From here, you should be able to reboot and the physical port name would
be removed from all devices which have it.
It appears to work on my test system running Fedora with systemd v256.
At any rate, this is fully an artifact of how systemd renames things and
I do not believe we should be working around that by modifying our drivers.
You're unlikely to convince systemd folks to change defaults, but you
might be able to convince some distributions to change their defaults.
Either way, you are best to work around this on your system in whichever
ways you see fit.
Thanks,
Jake
Powered by blists - more mailing lists