[systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV
Keller, Jacob E
jacob.e.keller at intel.com
Fri Aug 14 09:03:26 PDT 2015
On Fri, 2015-08-14 at 06:29 +0300, Andrei Borzenkov wrote:
>
> 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?
\-[0000:00]-+-00.0
+-01.0-[01-03]----00.0-[02-03]----08.0-[03]--+-00.0
| +-00.3
| \-00.4
+-01.1-[04-05]--+-00.0
| +-00.1
| +-00.2
| \-00.3
+-02.0-[06-09]----00.0-[07-09]--+-08.0-[08]--+-00.0
| | +-00.1
| | +-00.2
| | +-00.3
| | +-00.4
| | +-00.5
| | +-00.6
| | +-00.7
| | +-01.0
| | +-01.1
| | +-01.2
| | +-01.3
| | +-01.4
| | +-01.5
| | +-01.6
| | +-01.7
| | +-02.0
| | +-02.1
| | +-02.2
| | +-02.3
| | +-02.4
| | +-02.5
| | +-02.6
| | +-02.7
| | +-03.0
| | +-03.1
| | +-03.2
| | +-03.3
| | +-03.4
| | +-03.5
| | +-03.6
| | +-03.7
| | +-04.0
| | +-04.1
| | +-04.2
| | +-04.3
| | +-04.4
| | +-04.5
| | +-04.6
| | +-04.7
| | +-05.0
| | +-05.1
| | +-05.2
| | +-05.3
| | +-05.4
| | +-05.5
| | +-05.6
| | +-05.7
| | +-06.0
| | +-06.1
| | +-06.2
| | +-06.3
| | +-06.4
| | +-06.5
| | +-06.6
| | +-06.7
| | +-07.0
| | +-07.1
| | +-07.2>
> Could you show lspci -t with VF created?
\-[0000:00]-+-00.0
+-01.0-[01-03]----00.0-[02-03]----08.0-[03]--+-00.0
| +-00.3
| \-00.4
+-01.1-[04-05]--+-00.0
| +-00.1
| +-00.2
| \-00.3
+-02.0-[06-09]----00.0-[07-09]--+-08.0-[08]--+-00.0
| | +-00.1
| | +-00.2
| | +-00.3
| | +-00.4
| | +-00.5
| | +-00.6
| | +-00.7
| | +-01.0
| | +-01.1
| | +-01.2
| | +-01.3
| | +-01.4
| | +-01.5
| | +-01.6
| | +-01.7
| | +-02.0
| | +-02.1
| | +-02.2
| | +-02.3
| | +-02.4
| | +-02.5
| | +-02.6
| | +-02.7
| | +-03.0
| | +-03.1
| | +-03.2
| | +-03.3
| | +-03.4
| | +-03.5
| | +-03.6
| | +-03.7
| | +-04.0
| | +-04.1
| | +-04.2
| | +-04.3
| | +-04.4
| | +-04.5
| | +-04.6
| | +-04.7
| | +-05.0
| | +-05.1
| | +-05.2
| | +-05.3
| | +-05.4
| | +-05.5
| | +-05.6
| | +-05.7
| | +-06.0
| | +-06.1
| | +-06.2
| | +-06.3
| | +-06.4
| | +-06.5
| | +-06.6
| | +-06.7
| | +-07.0
| | +-07.1
| | +-07.2
| | +-07.3
| | +-07.4
| | +-07.5
| | +-07.6
| | +-07.7
| | \-08.0
| | +-07.3
| | +-07.4
| | +-07.5
| | +-07.6
| | +-07.7
| | \-08.0
I have also included a separate machine with a different device that
does a similar behavior:
\-[0000:00]-+-00.0
+-01.0-[01]--
+-01.1-[02-03]--+-00.0
| +-00.1
| +-00.2
| \-00.3
+-02.0-[04]--
+-03.0-[05]--
+-04.0
+-04.1
+-04.2
+-04.3
+-04.4
+-04.5
+-04.6
+-04.7
+-05.0
+-05.2
+-05.4
+-11.0-[06]--+-00.0
| \-00.3
+-16.0
+-16.1
+-1a.0
+-1c.0-[07-08]--+-[0000:08]-+-02.0
| | +-02.1
| | +-02.2
| | +-02.3
| | +-02.4
| | +-02.5
| | +-02.6
| | +-02.7
| | +-03.0
| | +-03.1
| | +-03.2
| | +-03.3
| | +-03.4
| | +-03.5
| | +-03.6
| | +-03.7
| | +-04.0
| | +-04.1
| | +-04.2
| | +-04.3
| | +-04.4
| | +-04.5
| | +-04.6
| | +-04.7
| | +-05.0
| | +-05.1
| | +-05.2
| | +-05.3
| | +-05.4
| | +-05.5
| | +-05.6
| | +-05.7
| | +-06.0
| | +-06.1
| | +-06.2
| | +-06.3
| | +-06.4
| | +-06.5
| | +-06.6
| | +-06.7
| | +-07.0
| | +-07.1
| | +-07.2
| | +-07.3
| | +-07.4
| | +-07.5
| | +-07.6
| | +-07.7
| | +-08.0
| | +-08.1
| | +-08.2
| | +-08.3
| | +-08.4
| | +-08.5
| | +-08.6
| | +-08.7
| | +-09.0
| | +-09.1
| | +-09.2
| | +-09.3
| | +-09.4
| | +-09.5
| | +-09.6
| | \-09.7
I have attached the full lspci -t output from each machine as well
incase it is helpful.
I also can find other devices which have multiple ports that generate
VFs, but I don't have any of these setup today.
Regards,
Jake
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-t-2.txt
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150814/b3913b9f/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci-t.txt
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150814/b3913b9f/attachment-0003.txt>
More information about the systemd-devel
mailing list