On 8/18/2020 8:35 PM, Jakub Kicinski wrote:
On Tue, 18 Aug 2020 20:43:11 -0600 David Ahern wrote:
On 8/18/20 6:24 PM, Jakub Kicinski wrote:
On Mon, 17 Aug 2020 15:50:53 +0300 Ido Schimmel wrote:
From: Ido Schimmel <ido...@nvidia.com>
This patch set extends devlink to allow device drivers to expose device
metrics to user space in a standard and extensible fashion, as opposed
to the driver-specific debugfs approach.
I feel like all those loose hardware interfaces are a huge maintenance
burden. I don't know what the solution is, but the status quo is not
great.
I don't agree with the 'loose' characterization.
Loose as in not bound by any standard or best practices.
Ido and team are pushing what is arguably a modern version of
`ethtool -S`, so it provides a better API for retrieving data.
ethtool -S is absolutely terrible. Everybody comes up with their own
names for IEEE stats, and dumps stats which clearly have corresponding
fields in rtnl_link_stats64 there. We don't need a modern ethtool -S,
we need to get away from that mess.
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?
As an example, per-queue stats have been
essential to me for recent investigations. ethq has been really helpful
in crossing NIC vendors and viewing those stats as it handles the
per-vendor naming differences, but it requires changes to show anything
else - errors per queue, xdp stats, drops, etc. This part could be simpler.
Sounds like you're agreeing with me?
As for this set, I believe the metrics exposed here are more unique to
switch ASICs.
This is the list from patch 6:
* - ``nve_vxlan_encap``
* - ``nve_vxlan_decap``
* - ``nve_vxlan_decap_errors``
* - ``nve_vxlan_decap_discards``
What's so unique?
At least one company I know of has built a business model
around exposing detailed telemetry of switch ASICs, so clearly some find
them quite valuable.
It's a question of interface, not the value of exposed data.
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? 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.
--
Florian
