[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bcd28773-0027-11f5-1fd9-0a793f0a3c3a@nvidia.com>
Date: Tue, 15 Sep 2020 23:33:30 +0300
From: Moshe Shemesh <moshe@...dia.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: Ido Schimmel <idosch@...sch.org>,
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
On 9/15/2020 4:34 PM, Jiri Pirko wrote:
> Tue, Sep 15, 2020 at 02:31:38PM CEST, moshe@...dia.com wrote:
>> On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>>> 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.
>>
>> 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.
>>>>> 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