Thread (42 messages) flat view 42 messages, 9 authors, 2016-02-24

Re: [patch net-next 0/9] Introduce devlink interface and first drivers to use it

From: Jiri Pirko <jiri@resnulli.us>
Date: 2016-02-23 16:23:13

Tue, Feb 23, 2016 at 05:19:37PM CET, gospo@cumulusnetworks.com wrote:
On Tue, Feb 23, 2016 at 05:01:31PM +0100, Jiri Pirko wrote:
quoted
Tue, Feb 23, 2016 at 04:55:28PM CET, gospo@cumulusnetworks.com wrote:
quoted
On Tue, Feb 23, 2016 at 03:45:51PM +0100, Jiri Pirko wrote:
quoted
Tue, Feb 23, 2016 at 03:34:19PM CET, gospo@cumulusnetworks.com wrote:

<snip>
quoted
quoted
quoted
quoted
	myhost:~$ dl port show
	devlink0/1: type eth netdev ens4
                            ^^^^^^^^^^^
quoted
	devlink0/2: type ib ibdev mlx4_0
                           ^^^^^^^^^^^^
I think my only other question about this implementation is whether or
not one would really want to have the true netdev/ibdev names mapped
here.

Would be as reasonable to simply specify the type (and there may be more
types within ethernet that could be useful in multi-chip configurations)
and then let normal infrastructure that exists today figure out how to
map the names for the netdevs to the devices?
What normal infrastructure you have in mind? There is no info about
devlink port mapping to netdev/ibdev anywhere. Only here. I might be
missing something but I fail to see what's wrong with it.
I was simply wondering out loud if we _really_ wanted to name netdevs
this way.  I was suggesting that output could be like this:

myhost:~$ dl port show
devlink0/1: type eth
devlink0/2: type ib 

mnd that udev/systemd/biosdevname/etc would take care of naming the
device whataever it wanted.  This appears to be essentially the same
concern Hannes has.
Wait. The only thing which will be renamed by udev is "devlink0". The
suffixes "/1" and "/2" are direct indexes as used inside the driver.

And you need some link to netdev in case netdev exists - therefore
"netdev ens4" attribute is there. There's no other way to get the
mapping of "devlink0/1" to "ens4" anywhere else.
So I think I had invisioned a slightly different workflow than what you
just described.

- Load PCI driver
- Setup devlink attributes for your hardware
- Create netdevs in network driver based on those attributes

You don't need a netdev to reference any of the devlink specific
parameters do you?
No, I have a devlink handle and a devlink port index. That is enough.
That's what I read as well and why I wondered why you said this:
quoted
quoted
quoted
And you need some link to netdev in case netdev exists - therefore
"netdev ens4" attribute is there. There's no other way to get the
mapping of "devlink0/1" to "ens4" anywhere else.
It just doesn't seem like referencing the netdev when performing set
operations was needed.

I see no issue having it appear a dump action after the fact, but
it seems like devlink[unit number]/[port number] would be enough to
reference the proper hardware mapping.  
I said nothing about needing netdev for set operation Andy. It is there
in a get list as an attribute for your convenience so you know what
netdev that specific port relates to. That's it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help