Tue, Sep 15, 2020 at 08:45:19AM CEST, ido...@idosch.org wrote:
>On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:51AM CEST, mo...@mellanox.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
>> > } ]
>> > }
>> > }
>> >}
>> >
>>
>> [..]
