On Mon, Jun 27, 2016 at 6:11 AM, Jiri Pirko <j...@resnulli.us> wrote: > Mon, Jun 27, 2016 at 03:02:31PM CEST, ro...@cumulusnetworks.com wrote:
[snip] >> >>The point of the stats api is to bring all stats together. >>ethtool stats are very valuable. so there is no point leaving them out. >>they will be in here sooner or later. >> >>when there is already a discussion of moving ethtool to netlink,..i am not >>sure >>I understand the hesitation on moving ethtool stats to netlink. > > It's not well defined. That's the issue. It's "debugfs"... > > >> >>> >>> >>> This patchset uses well defined values for slowpatch(/sw/cpu) stats. >>> That is I believe the only way to do this. >>> >> >>It seems to be your preferred way. I don't think it is the only way to >>do it. It can very well be part of the nested >>breakdown stats i am talking about. > > We are using existing well-defined structure. Very easy and clean. sure, it is well-defined. but my only point was the aggregate stats that the user or app cares about is in your so called already present 'well-defined structure'. everything else...ie the breakdowns are purely for debuggability and hence falls into the other bucket which you call "debugfs" like. splitting the kernel default interface stats into HW and SW is going to confuse people on the existing api and may introduce ambiguity for future stats is all i am saying.
