lkml.org 
[lkml]   [2021]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
Date
> -----Original Message-----
> From: Niklas Schnelle <schnelle@linux.ibm.com>
> Sent: Thursday, April 15, 2021 12:55 PM
> To: Bjorn Helgaas
> Cc: K, Narendra; Viktor Mihajlovski; Stefan Raspl; Peter Oberparleiter; linux-
> netdev@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-s390@vger.kernel.org
> Subject: Re: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
>
>
> [EXTERNAL EMAIL]
>
> On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> > > On s390 each PCI device has a user-defined ID (UID) exposed under
> > > /sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the
> > > PCI device's primary index and to match the device within Linux to
> > > the device configured in the hypervisor. To serve as a primary
> > > identifier the UID must be unique within the Linux instance, this is
> > > guaranteed by the platform if and only if the UID Uniqueness
> > > Checking flag is set within the CLP List PCI Functions response.
> > >
> > > In this sense the UID serves an analogous function as the SMBIOS
> > > instance number or ACPI index exposed as the "index" respectively
> > > "acpi_index" device attributes and used by e.g. systemd to set
> > > interface names. As s390 does not use and will likely never use ACPI
> > > nor SMBIOS there is no conflict and we can just expose the UID under the
> "index"
> > > attribute whenever UID Uniqueness Checking is active and get
> > > systemd's interface naming support for free.
> > >
> > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > > Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
> >
> > This seems like a nice solution to me.
> >
> > Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> Thanks! Yes I agree it's a simple solution that also makes sense from a design
> point. I'll wait for Narendra's opinion of course.

Hi Niklas,

It seems like the UID and the index are not equivalent in their meaning.

The index SMBIOS type 41 device type instance indicates that

1. The device is an onboard device.
2. A specific order of the onboard devices.

The UID described seems to indicate that the PCI device is unique within the Linux instance (sufficient for naming).
But it does not indicate that PCI device is onboard and any order.

As all devices with UID will be named as eno<UID> (Ethernet onboard), names are not in sync with how each PCI function is exposed on a PCI slot (appears
closer to SMBIOS type 9 record) as described below.

https://github.com/systemd/systemd/pull/19017
https://github.com/systemd/systemd/commit/a496a238e8ee66ce25ad13a3f46549b2e2e979fc

In summary, it seems like the eno<UID> names on s390 will be unique names, but may not match the meaning of the index.

Also,

a) Will UID remain unique/same as initially exposed across reboots ?

b) Is the reuse of index related to the 'slots' based naming scheme described below ?

https://github.com/systemd/systemd/pull/19017
https://github.com/systemd/systemd/commit/a496a238e8ee66ce25ad13a3f46549b2e2e979fc

c) If the slot based naming is fixed with the naming scheme from changes below, any thoughts on why is reuse of index needed ?

https://github.com/systemd/systemd/pull/19017
https://github.com/systemd/systemd/commit/a496a238e8ee66ce25ad13a3f46549b2e2e979fc

With regards,
Narendra K
\
 
 \ /
  Last update: 2021-04-16 19:59    [W:1.825 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site