Tue, Feb 23, 2016 at 05:19:37PM CET, go...@cumulusnetworks.com wrote: >On Tue, Feb 23, 2016 at 05:01:31PM +0100, Jiri Pirko wrote: >> Tue, Feb 23, 2016 at 04:55:28PM CET, go...@cumulusnetworks.com wrote: >> >On Tue, Feb 23, 2016 at 03:45:51PM +0100, Jiri Pirko wrote: >> >> Tue, Feb 23, 2016 at 03:34:19PM CET, go...@cumulusnetworks.com wrote: >> >> >> >> <snip> >> >> >> >> >> >> >> myhost:~$ dl port show >> >> >> >> devlink0/1: type eth netdev ens4 >> >> >> > ^^^^^^^^^^^ >> >> >> >> 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: > >> >> 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.
