[systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV

[Keller, Jacob E]

Hello,

I discussed this a while ago, but I have found that the hotplug slot
names for ethernet devices gets confused when SRIOV is used.

Basically:

I have a device plugged into a hotplug slot, and it gets

enp<bus>s<slot><f> for its PCI path name.

For the slot, it gets

ens<slot>

Example:

enp5s0

ens1

However, this device has SR-IOV functionality, and it creates new VFs
which appear at different functional bus:slot.func values.

In this device's case, as long as the particular layout for VFs puts
these in only functions 1-7 then I get

ens1f1
ens1f2
ens1f3

that is all great. However, devices are free to layout their SR-IOVs
into PCI cfg space at separate slots, ie: enp5s1f0 etc.

The issue comes up because *now* the hotplug slot functionality no
longer works: for some of the VFs, I get devices named above, others
now get

enp5s1f0

and so forth.

This is very confusing to the user as they use this device and don't
understand why it gets alternating user schemes.

I believe the error results from line 248 of udev-builtin-net_id.c

In this case, we check if we're a hotplug slot by checking if the bus
*and* slot are both equivalent. However, on my system all the hotplug
slots are always only at a specific bus, and not at a non-zero slot.

I honestly am not sure if this is a guarantee. Maybe I am wrong here?

If this is the case, then I'd suggest a modification to the hotplug
ules, so that it will match all

0000:05:XX.X

to match that slot at 0000:05:00.0, rather than only the functions.

I am not sure what the correct name scheme would be for ens1(some
subscript letter)<actual pci slot number?> would have to be.

However, it seems that the code is wrong today, and I end up having to
remove the hotplug slot from among the options when using this device.

Does anyone have any better suggestions?

Regards,
Jake