Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Kay Sievers]

On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch <Matt_Domsch at dell.com> wrote:

>    We
>    will need a method to enable/disable on a per-vendor basis as we
>    added to RHEL in the udev rules that invoke (or don't) biosdevname.
>    The suggestion of linking in (or not) rules files won't work for a
>    distro-wide per-vendor configuration.

Udev rules are installed in /usr/lib and can be "masked" by creating
empty files in /etc with the same file name. That way entire rules
files can be enabled/disabled, if needed.

If needed, we could add a kernel command line option to the rules too.

> C) There are several cases that biosdevname handles that udev doesn't
>    (yet) - NPAR and SR-IOV at least.  These are widely used in Dell
>    and other vendors' servers.

These SR-IOV show up with their own PCI function number in the kernel
and they are unique that way. From my point of view this is good
enough and we don't need to do anything here. If people want "pretty"
names they should provide custom and meaningful names on their own.
Udev does not want to establish any cross-device relations for naming,
and only look at the single device it is currently handling.

> D) the udev scheme will run out of characters in IFNAMSIZ (you've got
>    at most 15 chars to work with,

Sure, it's an unfortunate kernel limitation we have to live with. We
just do not rename anything if the name we composed does not fit. It's
not really a problem, more an exotic corner case that can be
covered/fixed by custom config if it really happens.

>    really less 5 because decimal-based
>    VLAN tagging is allowed, hence MAC-based won't fit).

VLANS do not need to be named with their number in the network device
name, they are created by custom config and not by detected hardware,
so the naming problem can be solved at that level too, instead of the
hardware-centric view udev has. For now, all VLANs are ignored by
udev.

>    Once you
>    allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254
>    as suffix), leaving you with 6 usable.

As mentioned above, the SR-IOV devices just get their PCI topology or
slot name, not the name of the parent device, and therefore they do
not run into the too long names.

>    You take 2 to define the
>    interface type (en,wl,ww), leaving 4 to describe the PCI topology.
>    Not gonna fit...

It fits, if we don't do the "pretty name" thing biosdevname does.

>    And last time I looked, we can't make IFNAMESIZ
>    bigger, as it's kernel ABI to userspace and used in a ton of
>    places.

Yeah, we cannot change that fact.

>   This is why the biosdevname naming convention is not as
>    pretty as yours

Well, the biosdevname names are surely prettier than the udev ones.

But the udev ones are predictable and have only one device to look at,
when the name is composed. There is zero other logic, that would
involve any global view of the system, or look at sibling devices;
hence the uglier, but more robust names.

>    there simply isn't enough space in IFNAMSIZ to do
>    much given the claims already on the space that we can't ignore.
>    "We can't solve that, so we won't" is not acceptable.  Real people
>    use these network features every day.

The compromise of biosdevname to make pretty names, like using shorter
numbers, or use the parent device as the basename for related devices,
are done at the cost of general reliability and dependence of crawling
the entire device tree to get a system overview, and make assumptions
based on the existence of other devices.

We liked the names biosdevname did, and wanted to do the same, but
udev just cannot do that, it is too fragile in hotplug setups to look
at anything but the device that is currently handled.

> E) In this thread, it has come up several times that biosdevname falls
>    back to an emumeration method in some cases where the BIOS
>    information is not present.  Yes, it does, though there are command
>    line flags that can disable that in general (e.g. --smbios26 means
>    it won't trigger unless the info is present in firmware).

Well, as always, defaults matter, not options in tools. And the
defaults of biosdevname did that guessing thing, which does not sound
right.

>    As I've
>    handed of maintenance of biosdevname to a whole engineering team, I
>    don't know the current state of any other enumeration codepaths,
>    but I agree, that's a lousy way to get the "right" answer, and I'm
>    sure the engineering team would take suggestions on how to fix it,
>    rather than 'throw out the baby with the bathwater'.

I think userspace enumeration as a general concept to start with
cannot work on today's systems. With a few exceptions, no device
naming should ever look at other devices for its own name, it's a
model that will break in many weird ways.

>  F) "sane" (to a programmer) PCI bus topology is getting more and more
>     difficult to come by, as multiple PCI roots now hang off specific
>     CPUs.  It will not be unusual for embedded devices to hang off the
>     second CPU slot, which may or may not be populated with a CPU.
>     We're long past the days where I can convince any motherboard
>     designers to physically route their boards to bring sanity to OS
>     device naming schemes.

Yeah, we can only try to be as good as we can. It's a problem we
cannot really solve, with no tool at the level of biosdevname or udev.

> So, in short, I support making Consistent Network Device Names
> better. But I'm not convinced the udev proposal is the right solution.
> I'd like to see an analysis of what I got wrong in biosdevname,
> proposals to fix those that don't cause even more problems, and then
> come to a solution.  I expect Lennart and Kay have already done this,
> but the only argument I keep hearing on this thread is "biosdevname
> sometimes does enumeration of its own - that's evil" which is correct,
> but not sufficient justification to throw it out.

Well, as outlined, we are strongly opposed to the concept of
"inventing" numbers, and look at the overall system state to come up
with naming properties, but that is the basic and inner concept of
biosdevname. Really, when we started we just though we would port the
interesting subset of biosdevname to udev and get the same names, but
it turned out to be impossible to get it as simple or dumb, reliable
and predictable as we need it in udev.

Biosdevname was still the pioneer in that are and we use all the stuff
it brought along from the basic ideas up to the kernel interfaces udev
can use now, but we already have a proven and well working naming
scheme in udev, which is used for disks and many other subsystems, and
it was from our point of view the better alternative and worth to
break the naming scheme for the sake of simplicity and reliability.

Thanks,
Kay