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: <hidden>
Date: 2013-06-10 17:56:33

-----Original Message-----
From: John Fastabend [mailto:john.fastabend@gmail.com]
Sent: Friday, June 07, 2013 11:05 PM
To: Ben Hutchings
Cc: John Fastabend; K, Narendra; stephen@networkplumber.org;
netdev@vger.kernel.org
Subject: Re: Generic interface to make physical port number used by a
netdevice available to user space

[...]
quoted
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).
Agreed, the qeth driver eluded me, its not in ./drivers/net as you noted in
the other thread.
quoted
[...]
quoted
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.
OK, sounds reasonable to me a new field should work.
1.  I think a universally unique physport identifier will be very useful.  If 'physport' is unique per NIC (say 0, 1, 2, 3) , then we would need PCI b/d/f to differentiate between two NICs.  But a universally unique identifier would not need any additional information. Also,  it seems like  the VM scenario  will not need any additional information if the VF (netdev) assigned to the guest exposes the unique identifier.

In the scenario of NIC partitions, universally unique identifier generation may have to consider that, each NIC partition which maps to a given physical port will have its own MAC address. (The SRIOV VF network interfaces could probably use PF's MAC address).  But  generation of a universally unique physport identifier would probably be driver specific.

2.  Also, thinking about the default value for 'physport' , could it be set to zero by default  ? A possible  interface could be

0   ==>   driver did not to set the identifier
0 ==> driver successfully set the identifier
With regards,
Narendra K
Linux Engineering
Dell Inc.
 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help