lkml.org 
[lkml]   [2020]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH net-next RFC v4 04/15] devlink: Add reload actions stats to dev get
From
Date

On 9/15/2020 11:33 PM, Moshe Shemesh wrote:
> External email: Use caution opening links or attachments
>
>
> On 9/15/2020 4:34 PM, Jiri Pirko wrote:
>> Tue, Sep 15, 2020 at 02:31:38PM CEST, moshe@nvidia.com wrote:
>>> On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>>>> Tue, Sep 15, 2020 at 08:45:19AM CEST, idosch@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, moshe@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.
>>>
>>> Sure, I will add it.
>> Could you please checkout the metrics patchset and figure out how to
>> merge that with your usecase?
>>
>
> I will check, I will discuss with Ido how it will fit.
>

I have discussed it with Ido, it doesn't fit to merge with metrics:

1. These counters are maintained by devlink unlike metrics which are
read by the driver from HW.

2. The metrics counters push string name, while here I use enum.

However, I did add another level as you suggested here for option to
future stats that may fit.

>>>>>> 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
>>>>>>>                  } ]
>>>>>>>          }
>>>>>>>      }
>>>>>>> }
>>>>>>>
>>>>>> [..]

\
 
 \ /
  Last update: 2020-09-18 18:14    [W:0.075 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site