Date:	Thu, 23 May 2013 20:49:39 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Dan Williams <dcbw@...hat.com>
CC:	<Narendra_K@...l.com>, <netdev@...r.kernel.org>
Subject: Re: Generic interface to make physical port number used by a
 netdevice available to user space

On Thu, 2013-05-23 at 14:05 -0500, Dan Williams wrote:
> On Thu, 2013-05-23 at 19:48 +0100, Ben Hutchings wrote:
> > On Thu, 2013-05-23 at 13:33 -0500, Dan Williams wrote:
> > > On Thu, 2013-05-23 at 17:18 +0100, Ben Hutchings wrote:
> > > > On Thu, 2013-05-23 at 06:27 -0700, Narendra_K@...l.com wrote:
> > > > > On Wed, May 22, 2013 at 09:34:18PM +0530, Ben Hutchings wrote:
> > > > > > 
> > > > > > On Wed, 2013-05-22 at 13:24 +0530, Narendra_K@...l.com wrote:
> > > > > > > While looking for already existing generic facility, 'dev_id' sysfs attribute
> > > > > > > seemed relevant. Looking into the sources seemed to indicate that majority of
> > > > > > > the drivers do not set it and it could be interpreted differently.
> > > > > > 
> > > > > > That is what it's for.  Unfortunately it is defined to be 0-based and as
> > > > > > you've seen the default (unknown) value is also 0, creating ambiguity.
> > > > > > (It also seems to be more common for user-facing documentation and
> > > > > > physical labels to use 1-based numbering.)
> > > > > > 
> > > > > > I wonder whether it would do any harm to make it signed and initialised
> > > > > > it to -1 in alloc_netdev_mqs() would do any harm?  That would make the
> > > > > > unknown case unambiguous.
> > > > > > 
> > > > > > > It would be great to know list's thoughts on  'dev_id' being used as the
> > > > > > interface
> > > > > > > to make the physical port number information used by netdevice available to
> > > > > > user
> > > > > > > space or do we need a new sysfs attribute for the same.
> > > > > > >
> > > > > > > Note: I think in the scenario of SRIOV VF devices assigned to guest and being
> > > > > > > bonded, additional information would be needed to differentiate the network
> > > > > > > controller in the host.  But I suppose it is a different problem than this.
> > > > > > 
> > > > > > You're thinking about hybrid guest acceleration?  A combination of PCIe
> > > > > > serial number and port number should work.
> > > > > 
> > > > > Hi Ben,
> > > > > 
> > > > > Thank you for the response.
> > > > > 
> > > > > I was thinking about the scenario of VF0 and VF1 coming from PF0 in the host
> > > > > Network Controller 1 being direct assigned to a KVM guest via VTD and netdevices
> > > > > from VF0 and VF1 being bonded in the guest. Assuming that physical port number used
> > > > > by VF0 and VF1 is 1, additional information is needed to identify if port number 1
> > > > > is on Network controller 1 or Network controller 2. (In the host we could use
> > > > > PCI b/d/f to differentiate two Network Controllers). I think it is similar to
> > > > > hybrid guest acceleration on the VF assignment aspect.
> > > > 
> > > > OK.  Either way, the hypervisor or management stack will have to help
> > > > the guest by providing the identifier(s) to tie the devices together.  I
> > > > suggested PCIe serial number as the controller identifier.
> > > 
> > > Forgive my ignorance, but is the PCIe serial number anything like the
> > > USB serial number?  Almost nobody sets a unique serial number for USB
> > > devices and often it's all zeros or 0123456789abcdef, so hopefully the
> > > PCIe one is saner.  If not, we shouldn't use it for anything important.
> > 
> > The PCIe serial number is specified as an EUI-64, which is trivially
> > derived from a MAC address.  So this is relatively easy to get right as
> > you need to assign unique MAC addresses anyway.  It's also an optional
> > capability, so there's no particular reason to set a dummy value.
> > 
> > That's not to say no-one ever gets this wrong.  SFC4000-based boards
> > have the bytes in reverse order.  Other potential mistakes would be
> > exposing different serial numbers in different functions, or changing
> > the serial number when the MAC address is temporarily changed.
> 
> Hmm, that's not making me feel warm and fuzzy inside when thinking about
> using this as an identifier of the parent interface.  If you happened to
> bond two interfaces and the firmware did change the serial number in
> response to a MAC address change, I think we'd be hosed, no?

If changing MAC address on a VF affects config space on the PF then the
device has *much* bigger problems!

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists