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.
>
>
> 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
> > } ]
> > }
> > }
> >}
> >
>
> [..]
