On Mon, Mar 2, 2015 at 1:17 PM, Tom Gundersen <t...@jklm.no> wrote: > Hi Jordan, > > On Mon, Mar 2, 2015 at 4:45 PM, Jordan Hargrave <jhar...@gmail.com> wrote: >> There are currently two competing naming mechanisms for network cards, >> biosdevname and systemd. Systemd currently has some limitations on naming >> cards that use network partitioning or support SR-IOV. > > Could you point to an example so we can fix it? I thought all bug > reports had been handled, but maybe I lost track of something. >
I have a quad-port NIC: 0000:40:00.0 = PCIE bridge (SMBIOS Slot 2) 0000:41:00.0 = Ethernet Device (port1) 0000:41:00.1 = Ethernet Device (port2) 0000:42:00.0 = Ethernet Device (port3) 0000:42:00.1 = Ethernet Device (port4) biosdevname would name these p2p1, p2p2, p2p3, p2p4 respectively. With systemd, it's ugly. I added the patch to get SMBIOS slot numbers and I see systemd get RANDOM names depending on boot. Either: s2f0 (p1) s2f1 (p2) p66s0f0 (p3) p66s0f1 (p4) I also saw the opposite: p65s0f0 (p1) p65s0f1 (p2) s2f0 (p3) s2f1 (p4) Since systemd doesn't have a concept of a 'port', whichever devices get named first (they are named in parallel, race conditions), the other devices have name collision (function 0,1 are duplicate, but on different bus). >> Proposal is to add >> support for biosdevname-like names as part of systemd. The names would be >> created as a new environment variable ID_NET_NAME_BIOSDEVNAME. This could >> then be used in the udev rules scripts to replace the external biosdevname >> handler. > > I don't think this makes much sense. If biosdevname had been > acceptable, the udev naming scheme would not have been introduced in > the first place. > biosdevname is going away in new version of RHEL, so we will lose the capability to detect if two 'virtual' NICs are actually the same physical NIC. The naming in systemd doesn't have the capabilty of showing relationship between physical/virtual (SR-IOV) NIC location name. >> At least on Dell systems, systemd generates unusable names (PCI B:D:F vs >> Slot#) for add-in cards as our PCIe slots do not have the ACPI _SUN method, >> but they do have a SMBIOS slot number. > > Wouldn't the better approach be to simply add SMBIOS support to udev > then? I must admit I don't know what challenges that entails, but > seems like a natural first step. > That could be possible. I've tried submitting a patch upstream for kernel but hasn't been accepted yet. So SMBIOS parsing would have to be part of systemd. > Cheers, > > Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
