mbox series

[v2,0/2] hv_netvsc: associate VF and PV device by serial number

Message ID 20180914195457.20433-1-sthemmin@microsoft.com (mailing list archive)
Headers show
Series hv_netvsc: associate VF and PV device by serial number | expand

Message

Stephen Hemminger Sept. 14, 2018, 7:54 p.m. UTC
The Hyper-V implementation of PCI controller has concept of 32 bit serial number
(not to be confused with PCI-E serial number).  This value is sent in the protocol
from the host to indicate SR-IOV VF device is attached to a synthetic NIC.

Using the serial number (instead of MAC address) to associate the two devices
avoids lots of potential problems when there are duplicate MAC addresses from
tunnels or layered devices.

The patch set is broken into two parts, one is for the PCI controller
and the other is for the netvsc device. Normally, these go through different
trees but sending them together here for better review. The PCI changes
were submitted previously, but the main review comment was "why do you
need this?". This is why.

v2 - slot name can be shorter.
     remove locking when creating pci_slots; see comment for explaination

Stephen Hemminger (2):
  PCI: hv: support reporting serial number as slot information
  hv_netvsc: pair VF based on serial number

 drivers/net/hyperv/netvsc.c         |  3 ++
 drivers/net/hyperv/netvsc_drv.c     | 58 ++++++++++++++++-------------
 drivers/pci/controller/pci-hyperv.c | 37 ++++++++++++++++++
 3 files changed, 73 insertions(+), 25 deletions(-)

Comments

David Miller Sept. 17, 2018, 2:59 p.m. UTC | #1
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 14 Sep 2018 12:54:55 -0700

> The Hyper-V implementation of PCI controller has concept of 32 bit serial number
> (not to be confused with PCI-E serial number).  This value is sent in the protocol
> from the host to indicate SR-IOV VF device is attached to a synthetic NIC.
> 
> Using the serial number (instead of MAC address) to associate the two devices
> avoids lots of potential problems when there are duplicate MAC addresses from
> tunnels or layered devices.
> 
> The patch set is broken into two parts, one is for the PCI controller
> and the other is for the netvsc device. Normally, these go through different
> trees but sending them together here for better review. The PCI changes
> were submitted previously, but the main review comment was "why do you
> need this?". This is why.
> 
> v2 - slot name can be shorter.
>      remove locking when creating pci_slots; see comment for explaination

Series applied, thanks.
Lorenzo Pieralisi Sept. 20, 2018, 2:18 p.m. UTC | #2
On Fri, Sep 14, 2018 at 12:54:55PM -0700, Stephen Hemminger wrote:
> The Hyper-V implementation of PCI controller has concept of 32 bit serial number
> (not to be confused with PCI-E serial number).  This value is sent in the protocol
> from the host to indicate SR-IOV VF device is attached to a synthetic NIC.
> 
> Using the serial number (instead of MAC address) to associate the two devices
> avoids lots of potential problems when there are duplicate MAC addresses from
> tunnels or layered devices.
> 
> The patch set is broken into two parts, one is for the PCI controller
> and the other is for the netvsc device. Normally, these go through different
> trees but sending them together here for better review. The PCI changes
> were submitted previously, but the main review comment was "why do you
> need this?". This is why.

The question was more whether we should convert this serial number into
a PCI slot number (that has user space visibility and that is what you are
after) to improve the current matching, I do not question why you need
it, just for the records.

Lorenzo

> v2 - slot name can be shorter.
>      remove locking when creating pci_slots; see comment for explaination
> 
> Stephen Hemminger (2):
>   PCI: hv: support reporting serial number as slot information
>   hv_netvsc: pair VF based on serial number
> 
>  drivers/net/hyperv/netvsc.c         |  3 ++
>  drivers/net/hyperv/netvsc_drv.c     | 58 ++++++++++++++++-------------
>  drivers/pci/controller/pci-hyperv.c | 37 ++++++++++++++++++
>  3 files changed, 73 insertions(+), 25 deletions(-)
> 
> -- 
> 2.18.0
>
Stephen Hemminger Sept. 20, 2018, 4:50 p.m. UTC | #3
On Thu, 20 Sep 2018 15:18:20 +0100
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:

> On Fri, Sep 14, 2018 at 12:54:55PM -0700, Stephen Hemminger wrote:
> > The Hyper-V implementation of PCI controller has concept of 32 bit serial number
> > (not to be confused with PCI-E serial number).  This value is sent in the protocol
> > from the host to indicate SR-IOV VF device is attached to a synthetic NIC.
> > 
> > Using the serial number (instead of MAC address) to associate the two devices
> > avoids lots of potential problems when there are duplicate MAC addresses from
> > tunnels or layered devices.
> > 
> > The patch set is broken into two parts, one is for the PCI controller
> > and the other is for the netvsc device. Normally, these go through different
> > trees but sending them together here for better review. The PCI changes
> > were submitted previously, but the main review comment was "why do you
> > need this?". This is why.  
> 
> The question was more whether we should convert this serial number into
> a PCI slot number (that has user space visibility and that is what you are
> after) to improve the current matching, I do not question why you need
> it, just for the records.

The name slot is way overloaded in this context.
There is 
	windows slot number which comes from Hyperv
	pci address slot which pci-hyperv sets from windows slot
	pci slot api value which for normal devices comes from ACPI
		this patch gets it from serial number


The netvsc driver needed to be able to find a PCI device based on the serial
number. The serial number was not visible in any current PCI-hyperv controller
values.  The windows slot (wslot) is not the same the serial number.