[systemd-devel] About stable network interface names

[Martin Wilck]

On Mon, 2017-05-29 at 02:35 +0200, Cesare Leonardi wrote:

> I ask because I've done several tests, with different motherboards, 
> adding and removing PCI-express cards and that expectation was not 
> satisfied in many cases.
> 
> For example, in one of those tests I initially had this setup:
> Integrated NIC: enp9s0
> PCIE1 (x1): dual port ethernet card [enp3s0, enp4s0]
> PCIE2 (x16): empty
> PCIE3 (x1): dual port ethernet card [enp7s0, enp8s0]
> 
> Then i inserted a SATA controller in the PCIE2 slot and three NICs
> got 
> renamed:
> Integrated NIC: enp10s0
> PCIE1 (x1): dual port ethernet card [enp3s0, enp4s0]
> PCIE2 (x16): empty
> PCIE3 (x1): dual port ethernet card [enp8s0, enp9s0]
> 
> Why?
> Didn't this interface naming scheme supposed to avoid this kind of
> renaming?
>  From what i've experimented network names are guaranteed to be
> stable 
> across reboots *and* if you doesn't add or remove hardware.

As others have remarked already, PCI bus-device-function is subject to
change.

Yet this highlights a problem with the current "predictable" network
device naming scheme. "biosdevname" uses information from various
sources, including ACPI _DSM method and SMBIOS type 41 and type 9. The
systemd device naming scheme (or the kernel code in pci-label.c, for
that matter) evaluates only _DSM and SMBIOS type 41, and not SMBIOS
type 9. The latter is necessary for mapping system PCI slot numbers to
bus-device-function tuples. Obviously, the physical slot a controller
is connected to is less likely to change than the bus-device-function
number, so exposing it might make a lot of sense.

All of this requires support on the BIOS/Firmware side - without that,
none of the "predictable" schemes work correctly.

Regards,
Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)