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

[Andrei Borzenkov]

On 14.08.2015 02:39, Keller, Jacob E wrote:
> 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.
>

Could you show lspci -t with VF created?

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>