Is it possible to undo the ixgbe device name change?

Is it possible to undo the ixgbe device name change?

[David Howells]

[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

Re: Is it possible to undo the ixgbe device name change?

[Andrew Lunn]

On Thu, Apr 24, 2025 at 07:06:56PM +0100, David Howells wrote:
> [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.

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

Re: Is it possible to undo the ixgbe device name change?

[Jakub Kicinski]

On Thu, 24 Apr 2025 23:32:12 +0200 Andrew Lunn wrote:
> > 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.  
> 
> 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.

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.

Re: Is it possible to undo the ixgbe device name change?

[David Howells]

Andrew Lunn <andrew@lunn.ch> wrote:

> Are you sure this patch is directly responsible? Looking at the patch

I bisected it to that commit.  Userspace didn't change.

> 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

Re: Is it possible to undo the ixgbe device name change?

[David Howells]

Andrew Lunn <andrew@lunn.ch> wrote:

> 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

Re: Is it possible to undo the ixgbe device name change?

[Andrew Lunn]

On Fri, Apr 25, 2025 at 09:58:35AM +0100, David Howells wrote:
> Andrew Lunn <andrew@lunn.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

Re: Is it possible to undo the ixgbe device name change?

[Jacob Keller]

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@lunn.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