lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 15 Sep 2020 15:34:06 +0200 From: Jiri Pirko <jiri@...nulli.us> To: Moshe Shemesh <moshe@...dia.com> Cc: Ido Schimmel <idosch@...sch.org>, Moshe Shemesh <moshe@...lanox.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...lanox.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH net-next RFC v4 04/15] devlink: Add reload actions stats to dev get Tue, Sep 15, 2020 at 02:31:38PM CEST, moshe@...dia.com wrote: > >On 9/15/2020 10:44 AM, Jiri Pirko wrote: >> Tue, Sep 15, 2020 at 08:45:19AM CEST, idosch@...sch.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@...lanox.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 >> > > > } ] >> > > > } >> > > > } >> > > > } >> > > > >> > > [..]
Powered by blists - more mailing lists