netdev - Re: [RFC 0/3] Adding config get/set to devlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21ab4a5d-0b6a-7976-7bf0-acd334f2613f@gmail.com>
Date:   Thu, 12 Oct 2017 12:20:07 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     jiri@...nulli.us, roopa@...ulusnetworks.com,
        steven.lin1@...adcom.com, netdev@...r.kernel.org,
        jiri@...lanox.com, michael.chan@...adcom.com,
        linux-pci@...r.kernel.org, linville@...driver.com,
        gospo@...adcom.com
Subject: Re: [RFC 0/3] Adding config get/set to devlink

On 10/12/2017 12:06 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@...il.com>
> Date: Thu, 12 Oct 2017 08:43:59 -0700
> 
>> Once we move ethtool (or however we name its successor) over to
>> netlink there is an opportunity for accessing objects that do and do
>> not have a netdevice representor today (e.g: management ports on
>> switches) with the same interface, and devlink could be used for
>> that.
> 
> That is an interesting angle for including this in devlink.
> 
> I'm not so sure what to do about this.
> 
> One suggestion is that devlink is used for getting ethtool stats for
> objects lacking netdev representor's, and a new genetlink family is
> used for netdev based ethtool.

Right, I was also thinking along those lines that we we would have a new
generic netlink family for ethtool to support ethtool over netlink.

> 
> I think it's important that we don't expand the scope of devlink
> beyond what it was originally designed for.

It seems to me like devlink is well defined in what it is not for: it is
not meant to be used for any object that is/has a net_device, but it is
not well defined for what it can offer to these non network devices. For
instance, we have a tremendous amount of operations that are extremely
specific to its single user(s) such as mlx5 and mlxsw.

For instance, I am not sure how the buffer reservation scheme can be
generalized, and this is always the tricky part with a single user
facility in that you try to generalize the best you can based on the HW
you know. This is not a criticism or meant to be anything negative, this
just happens to be the case, and we did not have anything better.

So maybe the first thing is to clarify what devlink operations can and
should be and what they are absolutely not allowed to cover. We should
also clarify whether a generic set/get that Steven is proposing is
something that we tolerate, or whether there should be specific function
pointers implemented for each attribute, which would be more in line
with what has been done thus far.
-- 
Florian