netdev - Re: [RFC PATCH net-next 0/6] devlink: Add device metric support

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 Aug 2020 09:18:43 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     David Ahern <dsahern@...il.com>, Ido Schimmel <idosch@...sch.org>,
        netdev@...r.kernel.org, davem@...emloft.net, jiri@...dia.com,
        amcohen@...dia.com, danieller@...dia.com, mlxsw@...dia.com,
        roopa@...dia.com, andrew@...n.ch, vivien.didelot@...il.com,
        tariqt@...dia.com, ayal@...dia.com, mkubecek@...e.cz,
        Ido Schimmel <idosch@...dia.com>
Subject: Re: [RFC PATCH net-next 0/6] devlink: Add device metric support

On Tue, 18 Aug 2020 21:30:16 -0700 Florian Fainelli wrote:
> >>> I spend way too much time patrolling ethtool -S outputs already.  
> >>
> >> But that's the nature of detailed stats which are often essential to
> >> ensuring the system is operating as expected or debugging some problem.
> >> Commonality is certainly desired in names when relevant to be able to
> >> build tooling around the stats.  
> > 
> > There are stats which are clearly detailed and device specific,
> > but what ends up happening is that people expose very much not
> > implementation specific stats through the free form interfaces,
> > because it's the easiest.
> > 
> > And users are left picking up the pieces, having to ask vendors what
> > each stat means, and trying to create abstractions in their user space
> > glue.  
> 
> Should we require vendors to either provide a Documentation/ entry for 
> each statistics they have (and be guaranteed that it will be outdated 
> unless someone notices), or would you rather have the statistics 
> description be part of the devlink interface itself? Should we define 
> namespaces such that standard metrics should be under the standard 
> namespace and the vendor standard is the wild west?

I'm trying to find a solution which will not require a policeman to
constantly monitor the compliance. Please see my effort to ensure
drivers document and use the same ethtool -S stats in the TLS offload
implementations. I've been trying to improve this situation for a long
time, and it's getting old.

Please focus on the stats this set adds, instead of fantasizing of what
could be. These are absolutely not implementation specific!

> > If I have to download vendor documentation and tooling, or adapt my own
> > scripts for every new vendor, I could have as well downloaded an SDK.  
> 
> Are not you being a bit over dramatic here with your example? 

I hope not. It's very hard/impossible today to run a fleet of Linux
machines without resorting to vendor tooling.

> At least  you can run the same command to obtain the stats regardless
> of the driver and vendor, so from that perspective Linux continues to
> be the abstraction and that is not broken.

Format of the data is no abstraction.