Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Kay Sievers]

On Tue, Feb 12, 2013 at 4:44 PM, Matt Domsch <Matt_Domsch at dell.com> wrote:

> I am concerned about the naming convention at installtime.  The
> current proposal removes biosdevname from comps @core as mandatory,
> and I presume would also remove it from the anaconda install
> environment as well.  This leaves the kernel default naming scheme,
> which we agree is poor.

The default scheme is always the udev names, if they are not
explicitly disabled. Everything else would be customization. We can
add whatever is needed here to help specific requirements.

>> 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.
>
> I disagree that users should provide their own "pretty" names, when we
> do have all the information we need about these devices to provide
> "pretty" names by default ourselves.  By the same argument, I don't
> need anything more from systemd/udevd now than I've had for years with
> 70-persistent-net.rules files.

Well, we cannot have everything, we either have somewhat fragile
pretty names composed by several sources and properties, spanning
multiple devices, and the overall system state. Or we have the "ugly"
but reliable and predictable names, which are a single device only.

Udev can only do the "ugly" version of the names, but the deal fits
better what we do for other subsystems, and is like "100 times"
simpler than what is required to do the pretty names. And reliability,
predictability, simplicity is actually what we looking for. We just
leave the pretty part to custom configuration.

> There are very good reasons to, in the device name, identify the
> separate (to the kernel) devices that represent the same physical
> cable jack.  Dell's engineers have been adding code to the bonding
> driver to recognize when someone is bonding two kernel devices that
> share a single physical cable jack, as that's not usually the intended
> configuration.  With the growing set of "applicance distributions"
> that auto-configure bonding across all visible network devices, this
> is even more important.

Sure, but custom config can add custom config for the used names too.
Having tools magically coming up with device names based on other
custom config is really nothing we ever would want to do. As soon as
custom config is in the game, there is really no need to try to be
smart, the tools that create the base config can create that config
along with it.

> The biosdevname convention of using _{1234} to identify such
> sub-devices is mirrored in your convention of appending f{1234}.
> Which works until you get to single PCI b/d/f devices with multiple
> ports (e.g. Mellanox adapters), after which you need further
> information to disambiguate the network devices.  The biosdevname
> maintainers are trying to tackle this right now.

This really sounds like the wrong layer of fixing the issue.

If Mellanox adapters create multiple interfaces per parent device, the
kernel driver should set the "dev_id" of the devices, which is an
index per instance to distinguish the devices. Udev will automatically
appended the dev_id to the device name as u1,u2,... and all the names
will be unique again. We already used dev_id for the persistent net
rules in old udev revisions.

This should work all fine without any further logic, as long as the
kernel driver do the right thing here. Inventing new numbers by
checking sibling devices should be avoided here too.

Thanks,
Kay