From: Stephen Hemminger <stephen@networkplumber.org>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: bhelgaas@google.com, kys@microsoft.com,
linux-pci@vger.kernel.org,
Stephen Hemminger <sthemmin@microsoft.com>
Subject: Re: [PATCH] PCI: hv: support reporting serial number as slot information
Date: Tue, 10 Jul 2018 16:11:11 -0700 [thread overview]
Message-ID: <20180710161111.68cbc667@xeon-e3> (raw)
In-Reply-To: <20180704160834.GB12996@red-moon>
On Wed, 4 Jul 2018 17:08:34 +0100
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Tue, Jun 12, 2018 at 09:40:37AM -0700, Stephen Hemminger wrote:
> > The Hyper-V host API for PCI provides a unique "serial number" which
> > can be used as the basis for sysfs PCI slot table. This can be useful
> > for cases where userspace wants to find the PCI device based on
> > serial number.
> >
> > When an SR-IOV NIC is added, the host sends an attach message
> > with a serial number. The kernel doesn't use the serial number, but
> > it is useful when doing the same thing in a userspace driver such
> > as the DPDK. By having /sys/bus/pci/slots/N it provides a direct
> > way to find the matching PCI device.
> >
> > There may be some cases where the serial number is not unique such
> > as when using GPU's. But the PCI slot infrastructure will handle
> > that.
> >
> > This also shortens the network device names generated by
> > systemd/udev. The new names use slot (ens2) rather than
> > PCI address (enP2p0s2).
>
> Hi Stephen,
>
> I wanted to apply this patch but wanted to make sure all HV
> maintainers are in agreement first since this looks like
> a significant user-space ABI change.
>
> I would also ask Bjorn's opinion on this since he has more
> insights into the slot interface history.
>
> Thanks,
> Lorenzo
It adds an API, but does not change existing sysfs entries.
The potential issues are more about how that new API will cause systemd/udev
to respond. It makes Hyper-V look more like KVM and that is generally
a good thing.
The systemd developers should like this change, but it may cause some
users to have problems since in general the existing udev model does
not do persistent names on PCI devices. But the PCI device for networking
is only used as a VF device paired with a PV device (netvsc). All network
configuration is done on the PV device; the name of the VF device doesn't
really matter.
The purpose of this was to take incremental steps to use the serial
number for matching PV and VF devices (rather than by MAC address).
There is ongoing work in DPDK (in userspace) where being able to find
a PCI device by serial number would be useful.
next prev parent reply other threads:[~2018-07-10 23:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-12 16:40 [PATCH] PCI: hv: support reporting serial number as slot information Stephen Hemminger
2018-07-04 16:08 ` Lorenzo Pieralisi
2018-07-10 23:11 ` Stephen Hemminger [this message]
2018-07-11 13:49 ` Bjorn Helgaas
2018-07-13 21:38 ` Stephen Hemminger
2018-07-19 16:58 ` Lorenzo Pieralisi
2018-07-19 17:36 ` Stephen Hemminger
2018-07-30 19:22 ` Stephen Hemminger
2018-07-19 17:28 ` Bjorn Helgaas
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=20180710161111.68cbc667@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=bhelgaas@google.com \
--cc=kys@microsoft.com \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=sthemmin@microsoft.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).