[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200921103339.GC2323@nanopsycho.orion>
Date: Mon, 21 Sep 2020 12:33:39 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Moshe Shemesh <moshe@...dia.com>
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
Fri, Sep 18, 2020 at 06:13:59PM CEST, moshe@...dia.com wrote:
>
>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@...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.
>>
>
>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.
Okay.
>
>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
>> > > > > > > } ]
>> > > > > > > }
>> > > > > > > }
>> > > > > > > }
>> > > > > > >
>> > > > > > [..]
Powered by blists - more mailing lists