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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130523132729.GA11584@fedora-17-guest.blr.amer.dell.com>
Date:	Thu, 23 May 2013 06:27:42 -0700
From:	<Narendra_K@...l.com>
To:	<bhutchings@...arflare.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: Generic interface to make physical port number used by a
 netdevice available to user space

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.

-- 
With regards,
Narendra K
Linux Engineering
Dell Inc.
--
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