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

Jordan Hargrave jharg93 at gmail.com
Mon Nov 9 17:41:02 PST 2015


On Mon, Nov 9, 2015 at 4:43 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 09.11.15 12:42, Jordan Hargrave (jharg93 at gmail.com) wrote:
>
>> From: Jordan Hargrave <jharg93 at gmail.com>
>>
>> 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>
>
> "partitions"? What's that supposed to be? SR-IOV?
>

Similar to SR-IOV but on Dell servers partitions actually show up as
PCI devices in the initial enumeration.  The PCI device vital product
data area has a map of which Bus:Dev:Func is which port and which port
instance.

So say we have a PCI device tree for a quad-port NIC, 4 physical ports
but 8 NICs.

04:00.0 port 1, instance 1
04:00.1 port 2, instance 1
04:00.2 port 3, instance 1
04:00.3 port 4, instance 1
04:00.4 port 1, instance 2
04:00.5 port 2, instance 2
04:00.6 port 3, instance 2
04:00.7 port 4, instance 2

We use this partition info to display if a bond is created that
contains the same physical nic port.

>> 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.
>
> Hmm, isn't this stuff the same as exported by the kernel as the
> "index" field, i.e. SMBIOS Type 41? Can you elaborate on the relation
> of that field and the stuff this patch adds?
>

 The index is exported for embedded devices, but not add-in cards.
acpi_index may be exported for add-in cards, but generally not very
useful as it has a number like 17 or 24... no relation to the actual
physical slot where a NIC is located.

>> Signed-off-by: Jordan Hargrave <jordan_hargrave at dell.com>
>
> I didn't look too closely in the actual sources, but I did notice that
> it is line-broken, and doesn't follow CODING_STYLE in quite a few
> cases, regarding placement of brackets, or error handling for
> example.
>
> In order to avoid any confusion with line-broken patches, and to make
> review easier, please submit the patch as github PR, which is the way
> we generally prefer receiving patches these days!

Where do I submit this?

>
> Thanks,
>
> Lennart
>
> --
> Lennart Poettering, Red Hat


More information about the systemd-devel mailing list