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
$ 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
} ]
}
}
}
Signed-off-by: Moshe Shemesh <[email protected]>
---
v3 -> v4:
- Renamed DEVLINK_ATTR_RELOAD_ACTION_CNT to
DEVLINK_ATTR_RELOAD_ACTION_STAT
- Add stats per action per limit level
v2 -> v3:
- Add reload actions counters instead of supported reload actions
(reload actions counters are only for supported action so no need for
both)
v1 -> v2:
- Removed DEVLINK_ATTR_RELOAD_DEFAULT_LEVEL
- Removed DEVLINK_ATTR_RELOAD_LEVELS_INFO
- Have actions instead of levels
---
include/uapi/linux/devlink.h | 3 +++
net/core/devlink.c | 45 ++++++++++++++++++++++++++++++++----
2 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index b19686fd80ff..ac9be467d243 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -495,6 +495,9 @@ enum devlink_attr {
DEVLINK_ATTR_RELOAD_ACTION, /* u8 */
DEVLINK_ATTR_RELOAD_ACTIONS_PERFORMED, /* nested */
DEVLINK_ATTR_RELOAD_ACTION_LIMIT_LEVEL, /* u8 */
+ DEVLINK_ATTR_RELOAD_ACTION_STATS, /* nested */
+ DEVLINK_ATTR_RELOAD_ACTION_STAT, /* nested */
+ DEVLINK_ATTR_RELOAD_ACTION_STAT_VALUE, /* u32 */
/* add new attributes above here, update the policy in devlink.c */
diff --git a/net/core/devlink.c b/net/core/devlink.c
index cbf746966913..1063b7a4123a 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -462,6 +462,11 @@ static int devlink_nl_put_handle(struct sk_buff *msg, struct devlink *devlink)
return 0;
}
+static bool devlink_reload_supported(struct devlink *devlink)
+{
+ return devlink->ops->reload_down && devlink->ops->reload_up;
+}
+
static bool
devlink_reload_action_is_supported(struct devlink *devlink, enum devlink_reload_action action)
{
@@ -479,7 +484,9 @@ static int devlink_nl_fill(struct sk_buff *msg, struct devlink *devlink,
enum devlink_command cmd, u32 portid,
u32 seq, int flags)
{
+ struct nlattr *reload_action_stats, *reload_action_stat;
+ int i, j, stat_idx;
void *hdr;
hdr = genlmsg_put(msg, portid, seq, &devlink_nl_family, flags, cmd);
if (!hdr)
@@ -490,9 +497,42 @@ static int devlink_nl_fill(struct sk_buff *msg, struct devlink *devlink,
if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_FAILED, devlink->reload_failed))
goto nla_put_failure;
+ if (!devlink_reload_supported(devlink))
+ goto out;
+
+ reload_action_stats = nla_nest_start(msg, DEVLINK_ATTR_RELOAD_ACTION_STATS);
+ if (!reload_action_stats)
+ goto nla_put_failure;
+
+ for (j = 0; j <= DEVLINK_RELOAD_ACTION_LIMIT_LEVEL_MAX; j++) {
+ if (!devlink_reload_action_limit_level_is_supported(devlink, j))
+ continue;
+ for (i = 0; i <= DEVLINK_RELOAD_ACTION_MAX; i++) {
+ if (!devlink_reload_action_is_supported(devlink, i))
+ continue;
+ reload_action_stat = nla_nest_start(msg, DEVLINK_ATTR_RELOAD_ACTION_STAT);
+ if (!reload_action_stat)
+ goto reload_action_stats_nest_cancel;
+ if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_ACTION, i))
+ goto reload_action_stat_nest_cancel;
+ if (nla_put_u8(msg, DEVLINK_ATTR_RELOAD_ACTION_LIMIT_LEVEL, j))
+ goto reload_action_stat_nest_cancel;
+ stat_idx = j * __DEVLINK_RELOAD_ACTION_MAX + i;
+ if (nla_put_u32(msg, DEVLINK_ATTR_RELOAD_ACTION_STAT_VALUE,
+ devlink->reload_action_stats[stat_idx]))
+ goto reload_action_stat_nest_cancel;
+ nla_nest_end(msg, reload_action_stat);
+ }
+ nla_nest_end(msg, reload_action_stats);
+ }
+out:
genlmsg_end(msg, hdr);
return 0;
+reload_action_stat_nest_cancel:
+ nla_nest_cancel(msg, reload_action_stat);
+reload_action_stats_nest_cancel:
+ nla_nest_cancel(msg, reload_action_stats);
nla_put_failure:
genlmsg_cancel(msg, hdr);
return -EMSGSIZE;
@@ -2961,11 +3001,6 @@ static void devlink_reload_netns_change(struct devlink *devlink,
DEVLINK_CMD_PARAM_NEW);
}
-static bool devlink_reload_supported(const struct devlink *devlink)
-{
- return devlink->ops->reload_down && devlink->ops->reload_up;
-}
-
static void devlink_reload_failed_set(struct devlink *devlink,
bool reload_failed)
{
--
2.17.1
Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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?
>
>$ 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
> } ]
> }
> }
>}
>
[..]
On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
> Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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.
>
>
> >
> >$ 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
> > } ]
> > }
> > }
> >}
> >
>
> [..]
Tue, Sep 15, 2020 at 08:45:19AM CEST, [email protected] wrote:
>On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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
>> > } ]
>> > }
>> > }
>> >}
>> >
>>
>> [..]
On 9/15/2020 10:44 AM, Jiri Pirko wrote:
> Tue, Sep 15, 2020 at 08:45:19AM CEST, [email protected] wrote:
>> On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>>> Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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.
>>>
>>> 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
>>>> } ]
>>>> }
>>>> }
>>>> }
>>>>
>>> [..]
On 9/15/2020 4:34 PM, Jiri Pirko wrote:
> Tue, Sep 15, 2020 at 02:31:38PM CEST, [email protected] wrote:
>> On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>>> Tue, Sep 15, 2020 at 08:45:19AM CEST, [email protected] wrote:
>>>> On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>>>>> Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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
>>>>>> } ]
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>> [..]
Tue, Sep 15, 2020 at 02:31:38PM CEST, [email protected] wrote:
>
>On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>> Tue, Sep 15, 2020 at 08:45:19AM CEST, [email protected] wrote:
>> > On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> > > Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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?
>
>> > >
>> > > 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
>> > > > } ]
>> > > > }
>> > > > }
>> > > > }
>> > > >
>> > > [..]
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, [email protected] wrote:
>>> On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>>>> Tue, Sep 15, 2020 at 08:45:19AM CEST, [email protected] wrote:
>>>>> On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>>>>>> Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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
>>>>>>> } ]
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>> [..]
Fri, Sep 18, 2020 at 06:13:59PM CEST, [email protected] 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, [email protected] wrote:
>> > > On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>> > > > Tue, Sep 15, 2020 at 08:45:19AM CEST, [email protected] wrote:
>> > > > > On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> > > > > > Mon, Sep 14, 2020 at 08:07:51AM CEST, [email protected] 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
>> > > > > > > ???????????????? } ]
>> > > > > > > ???????? }
>> > > > > > > ???? }
>> > > > > > > }
>> > > > > > >
>> > > > > > [..]