Re: [RFC PATCH net-next 0/2] devlink: Add port stats

[Jiri Pirko <jiri@resnulli.us>]

Mon, Apr 11, 2022 at 08:01:57PM CEST, kuba@kernel.org wrote:
>On Mon, 11 Apr 2022 12:31:53 +0200 Jiri Pirko wrote:
>> Fri, Apr 08, 2022 at 05:16:38AM CEST, kuba@kernel.org wrote:
>> >On Thu, 7 Apr 2022 11:40:48 +0300 Michael Guralnik wrote:  
>> >> This patch set adds port statistics to the devlink port object.
>> >> It allows device drivers to dynamically attach and detach counters from a
>> >> devlink port object.  
>> >
>> >The challenge in defining APIs for stats is not in how to wrap a free
>> >form string in a netlink message but how do define values that have
>> >clear semantics and are of value to the user.  
>> 
>> Wait, does all stats have to be well-defined? I mean, look at the
>> ethtool stats. They are free-form strings too. Do you mean that in
>> devlink, we can only have well-defines enum-based stats?
>
>That's my strong preference, yes.
>
>First, and obvious argument is that it make lazy coding less likely
>(see devlink params).
>
>More importantly, tho, if your stats are not well defined - users don't
>need to seem them. Really! If I can't draw a line between a statistic
>and device behavior then keep that stat in the register dump, debugfs 

During the DaveM's-only era, there was quite strict policy against any
debugfs usage. As far as I remember the claim was, find of define the
proper api or do your debug things out-of-tree.

Does that changed? I just want to make sure that we are now free to use
debugfs for exposuse of debugging info as "odd vendor stats".
Personally, I think it is good idea. I think that the rest of the kernel
actually uses debugfs like that.

Thanks!

>or /dev/null.
>
>That's why it's important that we talk about _what_ you're trying to
>expose.

Basically a mixture of quite generic things and very obscure device
specific items.