> -----Original Message----- > From: KY Srinivasan > Sent: Thursday, December 15, 2016 8:11 PM > To: Stephen Hemminger <step...@networkplumber.org>; Greg KH > <gre...@linuxfoundation.org> > Cc: o...@aepfle.de; jasow...@redhat.com; linux-ker...@vger.kernel.org; > bjorn.helg...@gmail.com; a...@canonical.com; de...@linuxdriverproject.org; > leann.ogasaw...@canonical.com; Haiyang Zhang <haiya...@microsoft.com> > Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on > serial numbers > > > > > -----Original Message----- > > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > > Behalf Of Stephen Hemminger > > Sent: Wednesday, December 14, 2016 3:52 PM > > To: Greg KH <gre...@linuxfoundation.org> > > Cc: o...@aepfle.de; jasow...@redhat.com; linux-ker...@vger.kernel.org; > > bjorn.helg...@gmail.com; a...@canonical.com; > > de...@linuxdriverproject.org; leann.ogasaw...@canonical.com; Haiyang > > Zhang <haiya...@microsoft.com> > > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on > serial > > numbers > > > > Normally, that would work but in this case we have one driver (netvsc) > > which is managing another driver which is unaware of Hyper-V or netvsc > > drivers existence. The callback is happening in netvsc driver and it > > needs to say "hey I know that SR-IOV device, it is associated with my > > network device". This problem is how to know that N is associated with > > V? The V device has to be a network device, that is easy. But then it > > also has to be a PCI device, not to bad. But then the netvsc code > > is matching based on hyper-V only PCI bus metadata (the serial #). > > > > The Microsoft developers made the rational decision not to go > modifying > > all the possible SR-IOV network devices from Intel and Mellanox to add > > the functionality there. That would have been much worse. > > > > Maybe, rather than trying to do the management in the kernel it > > could have been done better in user space. Unfortunately, this would > > only move the problem. The PCI-hyperv host driver could expose serial > > value through sysfs (with some pain). But the problem would be how > > to make a new API to join the two V and N device. Doing a private > > ioctl is worse than the notifier. > > All this has been discussed earlier in the thread. I think I have a > solution > to the problem: > The only PCI (non-VF) NIC that may be present in the VM is the emulated > NIC and > we know exactly the device ID and vendor ID of this NIC. Furthermore, > as a platform we are not going to be emulating additional NICs. So, > if the PCI NIC is not the emulated NIC, it must be a VF and we can > extract the > serial number.
How about direct pass-through NIC devices. Do they have vPCI serial number? And, the numbers should be different from VF NIC? Thanks, - Haiyang _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
