[systemd-devel] Network Interface Names: solution for a desktop OS

[Jordan Hargrave]

On Tue, Apr 12, 2016 at 5:39 PM, Xen <list at xenhideout.nl> wrote:
> Just want to summarize here very shortly.
>
>
> If you turn the hotplug naming scheme into something more attractive.
>
> If you turn the USB naming scheme into something more attractive.
>
> If you accept like a 99.9% confidence interval for waiting until
> hardware has shown itself, then taking the (embedded + pci bus) numbers
> and condensing that into a sequential list for ethernet and wireless
>
> And if you deal with any other naming scheme there might be.
>
> Then it would solve the utmost total majority of instability issues in
> the kernel loading the driver for multiple NICs in quick succession
> (this whole issue was mostly about very short intervals I believe) even
> if you don't have a 100.00000% guarantee (but you would have a rounded
> 100% guarantee) particularly if you take into account that
> networking+firewall+routing should perhaps not start for a production
> system that is very important if not all networking devices for it are
> present.
>
> If you are going to start routing and firewalling on non-present
> networking devices, you have a problem anyway and the current
> "PredictableNetworkInterfaceNames" is not going to solve that.
>
> Then you will have ethernet0 and wireless0 names for the majority (vast
> majority) of consumer devices out there.
>
> You will have an almost 100.000% guarantee that an ordinary user with 2
> ethernet NICs (like a motherboard with 2 ports) will never ever
> experience NIC swapping (eth0 becoming eth1 and vice versa).
>
> You will not see a difference for USB and hotplug because you only
> prettify the names, compared to the current system.
>
> The statistical likelihood of this ever going wrong for those 2 NICs is
> just very very very very small. I don't care what you say about NICs
> showing up 2 hours after the system is booted. If you have a system that
> has to wait 2 hours for a relevant or essential NIC, it is going to be
> nonfunctional anyway.
>
> If you feel I'm being thick, please say so. I feel I am (but do explain
> ;-)).
>
> I just don't see how this is going to turn into any problem ever for
> anyone. If you do the renaming prior to starting networking, it is
> nearly impossible EVER that this will impact real people in a real way.
>
> Maybe that is not acceptable. From my point of view currently with the
> knowledge I have, it would work out fine and "waiting for devices to be
> present before you act on it" seems like a very nice thing to do anyway.
> It feels nice to me.
>
> It is only relevant for networking setups and if both devices you need
> are not present (or even more) you should not act on it anyway and the
> system should fail. Or you should have a provision that you are alerted
> of networking hardware not having come online.
>
> There is not really any scenario where this condensing of enp3s0 names
> is going to cause a problem.
>
> And if it does, reboot you know ;-). But it is not going to happen.
> Consumer systems usually have one NIC (eth). Routers running systemd
> need to guarantee that both needed devices (or more) are present before
> starting networking. I bet it is not a problem for them to depend on
> fixed bus names, especially if they are embedded systems. But hardware
> failure would usually disrupt functioning anyway.
>
> And you could turn that system off if you wanted. It doesn't have to be
> the same for everyone, as long as it is convenient and usable for the
> majority. Right?
>
> All you need to do is wait a few seconds before you start renaming or
> wait on some defined trigger.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

I am the primary developer of biosdevname.  I've been wanting this
naming functionality built into systemd or even the OS itself.
Primarily I am interested in servers with multiple physical and
virtual NICs but getting it working on desktops would be a bonus as
well.

The problem lies in the mapping itself.  Network devices can be on a
single, dual, or even quad-port cards.  Each one of these ports can be
'virtualized' through SR-IOV or NIC partitioning, one physical card
can potentially have hundreds of virtual NICs.  Other cards implement
multiple network interfaces for a single PCI bus:dev:func pair.
SMBIOS table has a mapping from slot number to PCI device, this can be
used to determine the physical slot number of a network card (and its
ports).

So there are at least 4 variables that you must keep track of, for add-in cards

PCI slot #
NIC physical port # (for multi-port cards)
NIC device ID (Each physical port can implement multiple network
devices)  see mlx4 driver or i.
NIC partition number (each device can then have multiple
partitions/virtual devices)  See. SR-IOV or Dell NPAR (network
partitioning)

For embedded devices (onboard), PCI slot # is replaced by instance
number.  This is also available through SMBIOS.