netdev - Re: Generic interface to make physical port number used by a netdevice available to user space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 May 2013 13:33:48 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	Ben Hutchings <bhutchings@...arflare.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 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.

Dan

--
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