[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220412083454.7b2a545d@kernel.org>
Date: Tue, 12 Apr 2022 08:34:54 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Michael Guralnik <michaelgur@...dia.com>, netdev@...r.kernel.org,
jiri@...dia.com, ariela@...dia.com, maorg@...dia.com,
saeedm@...dia.com, moshe@...dia.com
Subject: Re: [RFC PATCH net-next 0/2] devlink: Add port stats
On Tue, 12 Apr 2022 10:16:26 +0200 Jiri Pirko wrote:
> Mon, Apr 11, 2022 at 08:01:57PM CEST, kuba@...nel.org wrote:
> >> 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.
I think the policy is "it's fine as long as it's read-only".
Which could be a problem if you want to parametrize the counters.
But then again based on this RFC IDK if you do.
> >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.
Powered by blists - more mailing lists