From: Hannes Frederic Sowa <hannes@stressinduktion•org>
To: Jiri Pirko <jiri@resnulli•us>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail•com>,
Daniel Borkmann <daniel@iogearbox•net>,
Jesper Dangaard Brouer <brouer@redhat•com>,
netdev@vger•kernel.org, davem@davemloft•net, idosch@mellanox•com,
eladr@mellanox•com, yotamg@mellanox•com, ogerlitz@mellanox•com,
yishaih@mellanox•com, dledford@redhat•com, sean.hefty@intel•com,
hal.rosenstock@gmail•com, eugenia@mellanox•com,
roopa@cumulusnetworks•com, nikolay@cumulusnetworks•com,
hadarh@mellanox•com, jhs@mojatatu•com, john.fastabend@gmail•com,
jeffrey.t.kirsher@intel•com, jbenc@redhat•com
Subject: Re: [patch net-next RFC 0/6] Introduce devlink interface and first drivers to use it
Date: Mon, 8 Feb 2016 13:11:41 +0100 [thread overview]
Message-ID: <56B885FD.2050305@stressinduktion.org> (raw)
In-Reply-To: <20160208105529.GB2090@nanopsycho.orion>
Hi,
On 08.02.2016 11:55, Jiri Pirko wrote:
> Mon, Feb 08, 2016 at 11:15:38AM CET, hannes@stressinduktion•org wrote:
>> Hello,
>>
>> On 06.02.2016 20:40, Jiri Pirko wrote:
>>> Fri, Feb 05, 2016 at 06:38:42PM CET, alexei.starovoitov@gmail•com wrote:
>>>> On Fri, Feb 05, 2016 at 11:01:22AM +0100, Hannes Frederic Sowa wrote:
>>>>>
>>>>> Okay. I see it more as changing mode of operation of hardware and thus has
>>>>> not really anything to do with networking. If you say you change ethernet to
>>>>> infiniband it has something to do with networking, sure. But I am fine with
>>>>> this, I just thought the code size could be reduced by adding this to sysfs
>>>>> quite a lot. I don't have a strong opinion on this.
>>>>
>>>> there is already a way to change eth/ib via
>>>> echo 'eth' > /sys/bus/pci/drivers/mlx4_core/0000:02:00.0/mlx4_port1
>>>>
>>>> sounds like this is another way to achieve the same?
>>>
>>> It is. However the current way is driver-specific, not correct.
>>
>> Why is driver specific not correct? Actually it is very much a device
>> specific thing, isn't it?
>
> Well, adding driver specific sysfs file called "driver_name_port_type"
> does not seem correct to me.
Why? PHYs are debugged like that? I thought that especially sysfs is the
right thing, it makes sure we can correctly identify a device. The logic
in devlink_alloc by just incrementing a counter and having the naming
policy be decided by driver registration time will introduce the same
problems like identifying devices by interfaces had before.
>>> For mlx5, we need the same, it cannot be done in this way. Do devlink is
>>> the correct way to go.
>>
>> Do two drivers already justify a new complete netlink api? Doesn't this
>> create the same problems like netdevice naming problems which needed multiple
>> years to become stable in case we have multiple cards or some administrator
>
> The thing is, other driver would use it as well, but there's no way to
> do it :) So vendors have their proprietary configuration utils. Devlink
> objective is to avoid those, to introduce vendor-neutral interface.
Ok, agreed. But multiple driver reuse the phy-sysfs routines, too. I
didn't see this to be a problem.
Anyway, I don't care if it is sysfs or something else, I am concerned
about the atomic_inc_return based identification of those devices.
>> reorders the cards (biosdevorder, systemd/udev issues)? Are ports always
>> stable? How can we have a 1:1 relationship with ifindexes and how can they be
>> stable? It is impossible to use that in scripts?
>
> Port index is setup by driver always, they have stable internal
> numbering. devlink device name is not stable (as for example netdev
> name), but can be easily identified by bus name and device name. I don't
> see a reason why udev cannot rename it according to some rules. By the
> way, this is very similar to phyX wireless devices.
Ok, understood. It just seems to be duplication of code with another name.
>>>> Why not hide echo/cat in iproute2 instead of adding parallel netlink api?
>>>> Or this is for switches instead of nics?
>>>> Then why it's not adding to switchdev?
>>>
>>> Note this is not specific to switch ASICs. This is for all network devices.
>>
>> That's actually my fear. The relationship from "devlink-names" to ifindexes I
>> didn't understand at all architecturally.
>
> Again, this is very similar to phyX wireless devices.
> I don't understand the reason for your fear :)
If, as you said, this gets integrated by systemd/udev and will change
names to stable ones before switching ports (so we don't accidentally
switch a wrong port) I am all fine. This is basically how net_devices
are handled.
Then my only argument is that this is too complex, but I can live with that.
Thanks,
Hannes
next prev parent reply other threads:[~2016-02-08 12:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 10:47 [patch net-next RFC 0/6] Introduce devlink interface and first drivers to use it Jiri Pirko
2016-02-03 10:47 ` [patch net-next RFC 1/6] Introduce devlink infrastructure Jiri Pirko
2016-02-11 14:31 ` Ivan Vecera
2016-02-11 16:54 ` Jiri Pirko
2016-02-03 10:47 ` [patch net-next RFC 2/6] mlxsw: Implement devlink interface Jiri Pirko
2016-02-03 10:47 ` [patch net-next RFC 3/6] mlxsw: Implement hardware messages notification using devlink Jiri Pirko
2016-02-03 10:48 ` [patch net-next RFC 4/6] mlx4: Implement devlink interface Jiri Pirko
2016-02-16 16:43 ` Or Gerlitz
2016-02-16 16:51 ` Jiri Pirko
2016-02-03 10:48 ` [patch net-next RFC 5/6] mlx4: Implement hardware messages notification using devlink Jiri Pirko
2016-02-03 10:48 ` [patch net-next RFC 6/6] mlx4: Implement port type setting via devlink interface Jiri Pirko
2016-02-03 13:31 ` [patch net-next RFC 0/6] Introduce devlink interface and first drivers to use it Jesper Dangaard Brouer
2016-02-03 13:33 ` Jiri Pirko
2016-02-03 15:17 ` Daniel Borkmann
2016-02-04 13:22 ` Hannes Frederic Sowa
2016-02-04 13:26 ` Jiri Pirko
2016-02-05 10:01 ` Hannes Frederic Sowa
2016-02-05 17:38 ` Alexei Starovoitov
2016-02-06 19:40 ` Jiri Pirko
2016-02-08 10:15 ` Hannes Frederic Sowa
2016-02-08 10:55 ` Jiri Pirko
2016-02-08 12:11 ` Hannes Frederic Sowa [this message]
2016-02-04 19:01 ` Rosen, Rami
2016-02-05 14:29 ` Jesper Dangaard Brouer
2016-02-07 20:18 ` roopa
2016-02-08 19:00 ` Doug Ledford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B885FD.2050305@stressinduktion.org \
--to=hannes@stressinduktion$(echo .)org \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=brouer@redhat$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=dledford@redhat$(echo .)com \
--cc=eladr@mellanox$(echo .)com \
--cc=eugenia@mellanox$(echo .)com \
--cc=hadarh@mellanox$(echo .)com \
--cc=hal.rosenstock@gmail$(echo .)com \
--cc=idosch@mellanox$(echo .)com \
--cc=jbenc@redhat$(echo .)com \
--cc=jeffrey.t.kirsher@intel$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=john.fastabend@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nikolay@cumulusnetworks$(echo .)com \
--cc=ogerlitz@mellanox$(echo .)com \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=sean.hefty@intel$(echo .)com \
--cc=yishaih@mellanox$(echo .)com \
--cc=yotamg@mellanox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox