Thread (16 messages) 16 messages, 6 authors, 2013-06-10

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

From: Ben Hutchings <hidden>
Date: 2013-06-07 17:21:23

On Fri, 2013-06-07 at 07:59 -0700, John Fastabend wrote:
On 5/31/2013 5:13 AM, Narendra_K@Dell.com wrote:
quoted
On Mon, May 27, 2013 at 06:39:00PM +0530, Narendra_K@Dell.com wrote:
quoted
quoted
-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Thursday, May 23, 2013 10:04 PM
To: K, Narendra
Cc: netdev@vger.kernel.org
One idea would be to reuse the mostly outdated if_port field.
As far as I can see only drivers using it are legacy drivers which support
AUI vs.
quoted
TP back in the old bad days of BNC Ethernet.
Hi Stephen, thank you.

I think if_port or dev_id would be fine. The difference seems to be  that
dev_id is already exported to sysfs.
I think the following options could be explored -

1. dev_id:
Do not initialize it to -1, but use it to indicate physical port number
used by netdevice.

It is currently being used for indicating physical port number and
is also being used to differentiate OS instances as noted here.
http://marc.info/?l=linux-netdev&m=136992115300526&w=2
My opinion would be to use dev_id as the comment in netdevice.h suggests
it can be used for this. I'm not sure the addrconf.c bits are still
valid.

If need be you could fix the check in addrconf to check for not -1.
Having looked at the qeth driver now, I think the comment in netdevice.h
should be changed to state that this is for distinguishing devices that
share a link-layer address, and the drivers using it for other purposes
should stop doing so (if that doesn't break userland).

[...]
quoted
3. Add a new field 'physport' to 'struct net_device' and export it to sysfs.
Probably not we already have two fields that seem ill-defined no reason
to add another to the confusion. If you absolutely can't make dev_id or
if_port coherent then maybe but I really think one of the above two will
work.
I think we should tighten up documentation and implementation of the
existing fields, but there is still a need for this new one.

One thing that needs to be clearly specified is the scope of the
physport identifier - the controller, board, physical machine, ... or
universe.  In a VM, controller and board scope are pretty useless as it
typically can't tell which devices belong to the same controller or
board anyway.  A universally unique identifier is probably not too hard
to implement as there is likely to be at least one MAC address
permanently assigned to each physical port.

Ben.
quoted
It would be great to know your thoughts on which of the above would be
preferable.

-- 
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help