Is it possible to undo the ixgbe device name change?
Subsystems (2)
[resent with mailing list addresses fixes]
Hi,
With commit:
a0285236ab93fdfdd1008afaa04561d142d6c276 ixgbe: add initial devlink support
the name of the device that I see on my 10G ethernet card changes from enp1s0 to enp1s0np0.
This is a bit of a problem for my test box because I have Network Manager set up static configuration for that enp1s0... which no longer exists when that commit is applied. I could change to enp1s0np0, but then this would no longer exist if I want to test a kernel that doesn't have that commit applied.
If the name doesn't exist, booting pauses for about a minute while NM tries to find it (probably a NM bug), so adding both names isn't an option either :-/
(I don't use DHCP for this adapter as it's directly wired to another test box)
Alternatively, as a compromise, might it be possible to omit the "np0" bit if the adapter only has one port?
Thanks,
David
Quoted 11 lines · David Howells
[resent with mailing list addresses fixes]
Hi,
With commit:
a0285236ab93fdfdd1008afaa04561d142d6c276 ixgbe: add initial devlink supportthe name of the device that I see on my 10G ethernet card changes from enp1s0 to enp1s0np0.
Are you sure this patch is directly responsible? Looking at the patch i see:
@@ -11617,6 +11626,11 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
}
strcpy(netdev->name, "eth%d");
pci_set_drvdata(pdev, adapter);
+
+ devl_lock(adapter->devlink);
+ ixgbe_devlink_register_port(adapter);
+ SET_NETDEV_DEVLINK_PORT(adapter->netdev, &adapter->devlink_port);+
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.
It is systemd which later renames it to enp1s0 or enp1s0np0. If you ask me, you are talking to the wrong people.
Andrew
Jakub Kicinski
maintainerQuoted 26 lines · On Thu, 24 Apr 2025 23:32:12 +0200 Andrew Lunn wrote:
Quoted 7 lines
With commit:
a0285236ab93fdfdd1008afaa04561d142d6c276 ixgbe: add initial devlink supportthe name of the device that I see on my 10G ethernet card changes from enp1s0 to enp1s0np0.
Are you sure this patch is directly responsible? Looking at the patch i see:
(quoted diff) +5
-0@@ -11617,6 +11626,11 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent) } strcpy(netdev->name, "eth%d"); pci_set_drvdata(pdev, adapter); + + devl_lock(adapter->devlink); + ixgbe_devlink_register_port(adapter); + SET_NETDEV_DEVLINK_PORT(adapter->netdev, &adapter->devlink_port); +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.
Quoted 2 lines
It is systemd which later renames it to enp1s0 or enp1s0np0. If you ask me, you are talking to the wrong people.
Hooking up the devlink port will add a suffix identifying the port, it comes via dev_get_phys_port_name(). Intel could possibly implement an empty ndo_get_phys_port_name to override. Tho, I do agree with you in principle that this is highly unfortunate -- in principle _adding_ attributes should not cause regressions :(
Maybe NM could be thought to use altnames. But that's not a silver bullet.
Quoted 1 line · Andrew Lunn
Are you sure this patch is directly responsible? Looking at the patch
I bisected it to that commit. Userspace didn't change.
Quoted 4 lines
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?
David
Quoted 5 lines · David Howells
Quoted 1 line · Andrew Lunn
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.
Quoted 10 lines
Quoted 4 lines
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
Quoted 7 lines
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 eth0I 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
Quoted 29 lines · Andrew Lunn
Quoted 5 lines · David Howells
Quoted 1 line · Andrew Lunn
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.
Quoted 10 lines
Quoted 4 lines
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 eth0Quoted 7 lines
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 eth0I presume the kernel message saying that the renaming happened is triggered by systemd-udevd?
Quoted 9 lines
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:
Quoted 20 lines
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 thephys_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.
Quoted 9 lines
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
Quoted 2 lines · Andrew Lunn
It is systemd which later renames it to enp1s0 or enp1s0np0. If you ask me, you are talking to the wrong people.
Aha! It can be configured with systemd-udev.
See https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
And also "man systemd.link".
# cat /etc/systemd/network/10-testnet.link [Match] MACAddress=00:11:22:33:44:55 <--- your MAC address here [Link] Description=Test Network Name=enp1s0 <--- the name you want here
David