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]

Date:   Fri, 13 Oct 2017 09:11:21 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        Steve Lin <steven.lin1@...adcom.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>,
        Michael Chan <michael.chan@...adcom.com>,
        linux-pci@...r.kernel.org,
        "John W. Linville" <linville@...driver.com>,
        Andy Gospodarek <gospo@...adcom.com>
Subject: Re: [RFC 0/3] Adding config get/set to devlink

Thu, Oct 12, 2017 at 11:53:56PM CEST, roopa@...ulusnetworks.com wrote:
>On Thu, Oct 12, 2017 at 12:20 PM, Florian Fainelli <f.fainelli@...il.com> wrote:
>> 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.
>
>new api is fine by me. The reason for suggesting devlink was because
>some of the devlink
>port_* ops are close to ethtool ops that can operate on a port/netdev.
>eg split_port could be a netdev operation
>unless you want to split before the netdev is created.

Let me correct you. The split is always devlink_port operation. In some
cases however when there is a mapping between devlink_port and netdev,
userspace part could translate netdev->devlink_port.


>
>There are some ops in devlink which are global hw parameters and not
>specific to a port, those fit perfectly with
>devlinks original goal.

There are 2 handles from the very beginning:
1) devlink - asic-wide handle
2) devlink_port - port handle