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  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:   Tue, 15 Sep 2020 09:44:02 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Moshe Shemesh <moshe@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jiri Pirko <jiri@...lanox.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next RFC v4 04/15] devlink: Add reload actions stats
 to dev get

Tue, Sep 15, 2020 at 08:45:19AM CEST, idosch@...sch.org wrote:
>On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:51AM CEST, moshe@...lanox.com wrote:
>> >Expose devlink reload actions stats to the user through devlink dev
>> >get command.
>> >
>> >Examples:
>> >$ devlink dev show
>> >pci/0000:82:00.0:
>> >  reload_action_stats:
>> >    driver_reinit 2
>> >    fw_activate 1
>> >    driver_reinit_no_reset 0
>> >    fw_activate_no_reset 0
>> >pci/0000:82:00.1:
>> >  reload_action_stats:
>> >    driver_reinit 1
>> >    fw_activate 1
>> >    driver_reinit_no_reset 0
>> >    fw_activate_no_reset 0
>> 
>> I would rather have something like:
>>    stats:
>>      reload_action:
>>        driver_reinit 1
>>        fw_activate 1
>>        driver_reinit_no_reset 0
>>        fw_activate_no_reset 0
>> 
>> Then we can easily extend and add other stats in the tree.
>> 
>> 
>> Also, I wonder if these stats could be somehow merged with Ido's metrics
>> work:
>> https://github.com/idosch/linux/commits/submit/devlink_metric_rfc_v1
>> 
>> Ido, would it make sense?
>
>I guess. My original idea for devlink-metric was to expose
>design-specific metrics to user space where the entity registering the
>metrics is the device driver. In this case the entity would be devlink
>itself and it would be auto-registered for each device.

Yeah, the usecase is different, but it is still stats, right.


>
>> 
>> 
>> >
>> >$ devlink dev show -jp
>> >{
>> >    "dev": {
>> >        "pci/0000:82:00.0": {
>> >            "reload_action_stats": [ {
>> >                    "driver_reinit": 2
>> >                },{
>> >                    "fw_activate": 1
>> >                },{
>> >                    "driver_reinit_no_reset": 0
>> >                },{
>> >                    "fw_activate_no_reset": 0
>> >                } ]
>> >        },
>> >        "pci/0000:82:00.1": {
>> >            "reload_action_stats": [ {
>> >                    "driver_reinit": 1
>> >                },{
>> >                    "fw_activate": 1
>> >                },{
>> >                    "driver_reinit_no_reset": 0
>> >                },{
>> >                    "fw_activate_no_reset": 0
>> >                } ]
>> >        }
>> >    }
>> >}
>> >
>> 
>> [..]

Powered by blists - more mailing lists