Messages in this thread | | | Subject | Re: [PATCH net-next RFC v4 04/15] devlink: Add reload actions stats to dev get | From | Moshe Shemesh <> | Date | Fri, 18 Sep 2020 19:13:59 +0300 |
| |
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 >>>>>>> } ] >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>> [..]
| |