Proposed F19 Feature: systemd/udev Predictable Network Interface Names

Tue Feb 12 15:44:00 UTC 2013

On Thu, Feb 07, 2013 at 09:22:40PM -0600, Kay Sievers wrote:
> 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.

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.  So I also presume this proposal will be
extended to enable systemd/udevd naming at installtime, which for all
network installs the device naming is prompted for on screen and/or
read from kickstart files.  In this proposal there is no way to use
biosdevname names at installtime, or disable systemd/udevd names
entirely if so desired (akin to biosdevname=0 on the kernel command
line).  The RHEL model of disabling biosdevname by some hardware
vendors, at installtime, is not accounted for in the current proposal.

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

We do need this.  We also need to be able to enable biosdevname at
installtime, again by kernel command line.  The existing biosdevname=1
flag seems a good choice.

I am less concerned about runtime, as actions can be taken at runtime
to enable/disable/change the naming conventions for future boots.  I
agree anything can be done at runtime given a smart system
administrator (as much as I would like not to rely on a smart system
administrator for each install).

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

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.

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.

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.

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

VLAN devices are created in userspace by vconfig, with its own naming
policy:

* name-type:  VLAN_PLUS_VID (vlan0005), VLAN_PLUS_VID_NO_PAD (vlan5),
              DEV_PLUS_VID (eth0.0005), DEV_PLUS_VID_NO_PAD (eth0.5)

I agree udev doesn't need to know about them explicitly, but the
naming convention does need to account for that use of IFNAMSIZ space.

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

I agree, that's the right approach, which is why Dell pushed to get
the SMBIOS and PCI specifications amended to put explicit per-device
information into there.  I hope we can work together to do likewise
for cases coming up now that aren't currently addressed.

If we can solve the installtime naming convention choice to not
eliminate biosdevname, be able to disable systemd/udevd naming, and
have the default be possible on a per-system-vendor basis, and solve
the NPAR/SR-IOV/Mellanox naming problems, then I can support this
proposal.  Without fixing these shortcomings though, my customers will
have a fit at me.

Thanks,
Matt

--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130212/58cb156c/attachment.sig>