Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Matt Domsch]

I haven't chimed in on this thread yet, and as the original
biosdevname author, I suppose I should.  Some points of consideration,
which I had shared with Lennart and Kay when they first showed me
their work.

A) I'm glad to see someone else recognize and want to tackle
   this. Doing it in udev makes a lot of sense, and will certainly
   force more distros and hardware vendors to use it.  RHEL6 still has
   it enabled only for Dell systems, by request of (other hardware
   vendors) who didn't want to inflict biosdevname on their users.  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.

B) I have had far more positive feedback about the effectiveness of
    biosdevname from Dell customers than I have negative.  They love
    that finally the physical external chassis labels have a direct
    correlation to the Linux (and Windows Server 2012 if you're
    counting) device name.
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.

D) the udev scheme will run out of characters in IFNAMSIZ (you've got
   at most 15 chars to work with, really less 5 because decimal-based
   VLAN tagging is allowed, hence MAC-based won't fit).  Once you
   allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254
   as suffix), leaving you with 6 usable.  You take 2 to define the
   interface type (en,wl,ww), leaving 4 to describe the PCI topology.
   Not gonna fit...  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.  This is why the biosdevname naming convention is not as
   pretty as yours - 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.

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


 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.


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.

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/20130207/a1ca1d97/attachment.sig>