linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "K, Narendra" <Narendra.K@dell.com>
To: Viktor Mihajlovski <mihajlov@linux.ibm.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Bjorn Helgaas <helgaas@kernel.org>
Cc: Stefan Raspl <raspl@linux.ibm.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	"linux-netdev@vger.kernel.org" <linux-netdev@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"K, Narendra" <Narendra.K@dell.com>
Subject: RE: [PATCH 1/1] s390/pci: expose a PCI device's UID as its index
Date: Sun, 18 Apr 2021 08:18:10 +0000	[thread overview]
Message-ID: <BYAPR19MB471163449D3A0627DD547EA7814A9@BYAPR19MB4711.namprd19.prod.outlook.com> (raw)
In-Reply-To: <7765cc9a-7e21-708a-1286-a8340d4874ca@linux.ibm.com>

> -----Original Message-----
> From: Viktor Mihajlovski <mihajlov@linux.ibm.com>
> Sent: Saturday, April 17, 2021 4:18 PM
> To: K, Narendra; Niklas Schnelle; Bjorn Helgaas
> Cc: 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 4/16/21 7:58 PM, K, Narendra wrote:
> >> -----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.
> >
> Hi Narendra,
> 
> the reasoning behind the wish to reuse index is that we think it's similar in the
> sense that it provides a stable, firmware-reported interface identifier.
> Some background: s390 is a highly virtualized platform. There's no traditional
> bare metal mode of operation, neither for the computer system nor the I/O
> subsystem.
> The equivalent to a standalone system is a logical partition (LPAR) which in
> essence is a kind of virtual machine. LPARs access I/O devices in a virtualized
> fashion as well. E.g., for PCI devices the I/O subsystem is responsible for the
> management of PCI hardware and will provide the PCI functions to the LPARs.
> This is where UID and function_id come into play. Each PCI function will carry a
> function_id attribute which defines it uniquely within the entire s390 system. If
> a UID is configured for the function, it must be unique within an LPAR, but
> doesn't need to be unique system-wide.
> For instance, the admistrator may want to ensure that for every LPAR the
> primary ethernet interface has the same identifier, to allow miigration of Linux
> instances accross LPARs.
> This can't be achieved with a slot-based name.
> > 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://urldefense.com/v3/__https://github.com/systemd/systemd/pull/19
> > 017__;!!LpKI!zDeT5hnnMp8tFNAzwNWtW3-
> C6w7p4FBLldAu705T3EPicJZNI7TewsdZa
> > LDBMQ$ [github[.]com]
> >
> https://urldefense.com/v3/__https://github.com/systemd/systemd/commit/
> >
> a496a238e8ee66ce25ad13a3f46549b2e2e979fc__;!!LpKI!zDeT5hnnMp8tFNAz
> wNWt
> > W3-C6w7p4FBLldAu705T3EPicJZNI7TewsfDTU8TaQ$ [github[.]com]
> >
> > 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 ?
> Yes, the UID is the primary identifier for a PCI function and part of the LPAR
> configuration. Even hotplug will not change the UID.
> >
> > b) Is the reuse of index related to the 'slots' based naming scheme described
> below ?
> >
> > https://urldefense.com/v3/__https://github.com/systemd/systemd/pull/19
> > 017__;!!LpKI!zDeT5hnnMp8tFNAzwNWtW3-
> C6w7p4FBLldAu705T3EPicJZNI7TewsdZa
> > LDBMQ$ [github[.]com]
> >
> https://urldefense.com/v3/__https://github.com/systemd/systemd/commit/
> >
> a496a238e8ee66ce25ad13a3f46549b2e2e979fc__;!!LpKI!zDeT5hnnMp8tFNAz
> wNWt
> > W3-C6w7p4FBLldAu705T3EPicJZNI7TewsfDTU8TaQ$ [github[.]com]
> >
> No, this is independent. The commit above fixes the slot name parsing.
> > 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://urldefense.com/v3/__https://github.com/systemd/systemd/pull/19
> > 017__;!!LpKI!zDeT5hnnMp8tFNAzwNWtW3-
> C6w7p4FBLldAu705T3EPicJZNI7TewsdZa
> > LDBMQ$ [github[.]com]
> >
> https://urldefense.com/v3/__https://github.com/systemd/systemd/commit/
> >
> a496a238e8ee66ce25ad13a3f46549b2e2e979fc__;!!LpKI!zDeT5hnnMp8tFNAz
> wNWt
> > W3-C6w7p4FBLldAu705T3EPicJZNI7TewsfDTU8TaQ$ [github[.]com]
> As I wrote above, the slot describes the PCI function at the system level,
> whereas the uid/index does it in the context off the LPAR.

Hi Viktor,

Thank you for the context and clarification. 

I am not familiar with s390 and have not reviewed the patch. Please find the ack for reuse of  '/sys/bus/pci/devices/.../index'  sysfs attribute. 

Acked-by: Narendra K <narendra_k@dell.com>

With regards,
Narendra K



  reply	other threads:[~2021-04-18  8:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 13:59 [PATCH 0/1] Use of /sys/bus/pci/devices/…/index for non-SMBIOS platforms Niklas Schnelle
2021-04-12 13:59 ` [PATCH 1/1] s390/pci: expose a PCI device's UID as its index Niklas Schnelle
2021-04-14 20:17   ` Bjorn Helgaas
2021-04-15  7:24     ` Niklas Schnelle
2021-04-16 17:58       ` K, Narendra
2021-04-17 10:47         ` Viktor Mihajlovski
2021-04-18  8:18           ` K, Narendra [this message]
2021-04-13  5:39 ` [PATCH 0/1] Use of /sys/bus/pci/devices/…/index for non-SMBIOS platforms Leon Romanovsky
2021-04-13  6:57   ` Niklas Schnelle
2021-04-13  7:32     ` Leon Romanovsky
2021-04-13  7:53       ` Niklas Schnelle
2021-04-13 18:22 ` K, Narendra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR19MB471163449D3A0627DD547EA7814A9@BYAPR19MB4711.namprd19.prod.outlook.com \
    --to=narendra.k@dell.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-netdev@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mihajlov@linux.ibm.com \
    --cc=oberpar@linux.ibm.com \
    --cc=raspl@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).