On Thu, 20 Aug 2020 08:35:25 -0600 David Ahern wrote: > On 8/19/20 12:07 PM, Jakub Kicinski wrote: > > I don't have a great way forward in mind, sadly. All I can think of is > > that we should try to create more well defined interfaces and steer > > away from free-form ones. > > There is a lot of value in free-form too.
On Tue, 18 Aug 2020 20:35:01 -0700 Jakub Kicinski wrote: > It's a question of interface, not the value of exposed data. > > Example, here if the stats are vxlan decap/encap/error - we should > > expose that from the vxlan module. That way vxlan module defines one > > set of stats for everyone. > > > > In general unless we attach stats to the object they relate to, we will > > end up building parallel structures for exposing statistics from the > > drivers. I posted a set once which was implementing hierarchical stats, > > but I've abandoned it for this reason. > > > [...] > > > > IDK. I just don't feel like this is going to fly, see how many names > > people invented for the CRC error statistic in ethtool -S, even tho > > there is a standard stat for that! And users are actually parsing the > > output of ethtool -S to get CRC stats because (a) it became the go-to > > place for NIC stats and (b) some drivers forget to report in the > > standard place. > > > > The cover letter says this set replaces the bad debugfs with a good, > > standard API. It may look good and standard for _vendors_ because they > > will know where to dump their counters, but it makes very little > > difference for _users_. If I have to parse names for every vendor I use, > > I can as well add a per-vendor debugfs path to my script. > > > > The bar for implementation-specific driver stats has to be high. > > My take away from this is you do not like the names - the strings side > of it. > > Do you object to the netlink API? The netlink API via devlink? > > 'perf' has json files to describe and document counters > (tools/perf/pmu-events). Would something like that be acceptable as a > form of in-tree documentation of counters? (vs Documentation/networking > or URLs like > https://community.mellanox.com/s/article/understanding-mlx5-ethtool-counters) Please refer to what I said twice now about the definition of the stats exposed here belonging with the VxLAN code, not the driver. > > Okay, fair. I just think that in datacenter deployments we are way > > closer to the SDK model than people may want to admit. > > I do not agree with that; the SDK model means you *must* use vendor code > to make something work. Your argument here is about labels for stats and > an understanding of their meaning. Sure, no "must" for passing packets, but you "must" use vendor tooling to operate a fleet. Since everybody already has vendor tools what value does this API add? I still need per vendor logic. Let's try to build APIs which will actually make user's life easier, which users will want to switch to.
