[systemd-devel] Fwd: [PATCH] Add support for detecting NIC partitions on Dell Servers

[Tom Gundersen]

On Tue, Nov 10, 2015 at 2:29 PM, Jordan Hargrave <jharg93 at gmail.com> wrote:
> On Tue, Nov 10, 2015 at 4:53 AM, Kay Sievers <kay at vrfy.org> wrote:
>> On Tue, Nov 10, 2015 at 5:49 AM, Jordan Hargrave <jharg93 at gmail.com> wrote:
>>> Cleaned up linux coding style
>>>
>>> This patch will integrate some of the features of biosdevname into systemd.
>>> The code detects the port and index for detecting NIC partitions. This creates
>>> a new environment variable, ID_NET_NAME_PARTITION of the format
>>> <PORT>_<PARTITION>
>>>
>>> The patch will also decode SMBIOS slot number for NIC, and store in the variable
>>> ID_NET_NAME_SMBIOS_SLOT.  Systemd does not have a method for naming
>>> ports on a multi-port card plugged into a slot.
>>
>> Again, I don't think systemd should carry an SMBIOS parser.
>>
>> Sorry,
>> Kay
>
> From a customer usability standpoint, having the slot numbers as part
> of systemd would be a very useful feature.

Sure, but I think Kay's point was that the needed info should be
exposed from the kernel in a sysattr, not be parsed from udev. Any
reason this cannot be done that way?

>  The current method only
> works for single-port NICs in a slot.  Multi-port NICs, especially
> ones with SR-IOV or multiple partitions get garbled names like

Just to make sure we are on the same page, when you say "garbled" you
mean that the naming scheme is not the one you want, but there are no
bugs here, right?

> enp4s0
> enp4s1
> enp4s0d1
> enp4s0f1
> enp4s0f2
> enp4s0f3
> enp4s0f4
> enp4s0f5
> enp4s0f6
> enp4s0f7
> enp4s0f1d1
> enp4s0f2d1
> enp4s0f3d1
> enp4s0f4d1
> enp4s0f5d1
> enp4s0f6d1
> enp4s0f7d1
> enp4s1d1
> enp68s0f0
> enp68s0f1
> enp69s0f0
> enp69s0f1
>
> That's another annoying thing with systemd names, the bus number is
> *decimal*.  lspci is in hex, so the customer has to do a conversion to
> figure out even what PCI device that is.

I guess too late to change that now.

> All enp4xxxx are a dual-port NIC in Slot 3 with 8 SR-IOV devices.

Hm, there are 17 devices listed, shouldn't there be 16 based on your
description?

> All enp68xx and enp69xxx are a single quad-port NIC in slot 2.
> Systemd breaks here if trying to name using slot numbers with the
> existing method.  As there are 4 devices under the slot with same
> device numbers, systemd would name them
> ens2f0
> ens2f1
> ens2f0
> ens2f1
>
> Which causes name collision.  I was able to verify this as either they
> got named:
> ens2f0
> ens2f1
> enp69s0f0
> enp69s0f1
>
> or
> enp68s0f0
> enp68s0f1
> ens2f0
> ens2f1
>
> at startup.
>
> That's the best feature of biosdevname, being able to tell which slot
> the NIC is located just from the name.  Systemd still has some
> limitations and/or bugs in this regard.

So how would your proposed naming scheme look in the examples you
gave? Is the information needed to generate the name taken from the
device in question or any of its parent devices (but never from its
siblings or other devices) and hence independent of probe-ordering?

Cheers,

Tom