On Wed, May 22, 2013 at 09:34:18PM +0530, Ben Hutchings wrote:

On Wed, 2013-05-22 at 13:24 +0530, Narendra_K@Dell.com wrote:

quoted

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.

quoted

It would be great to know list's thoughts on  'dev_id' being used as the

interface

quoted

to make the physical port number information used by netdevice available to

user

quoted

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.