| Message ID | 1600063682-17313-5-git-send-email-moshe@mellanox.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add devlink reload action and | expand |
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. > > > 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, 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. >> >> >> 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, 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. >>> >>> 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, 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? > >> > > >> > > 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, 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. >>>>> 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, 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 >>>>>>> } ] >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>> [..]
Fri, Sep 18, 2020 at 06:13:59PM CEST, moshe@nvidia.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@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. 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 >> > > > > > > } ] >> > > > > > > } >> > > > > > > } >> > > > > > > } >> > > > > > > >> > > > > > [..]
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) {
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 <moshe@mellanox.com> --- 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(-)