On 9/15/2020 10:44 AM, Jiri Pirko wrote:
Tue, Sep 15, 2020 at 08:45:19AM CEST, ido...@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, mo...@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
} ]
}
}
}
[..]
