On Fri, Jun 17, 2016 at 7:54 AM, Jamal Hadi Salim <j...@mojatatu.com> wrote: > On 16-06-17 10:05 AM, Jiri Pirko wrote: >> >> Fri, Jun 17, 2016 at 03:48:35PM CEST, d...@cumulusnetworks.com wrote: >>> >>> On 6/17/16 2:24 AM, Jiri Pirko wrote: >>>> >>>> > >> >> That is problematic. Existing apps depend on rtnetlink stats. But if we >> don't count offloaded forwarded packets, the apps don't see anything. >> Therefore I believe that this patchset approach is better. The existing >> apps continue to work and future apps can use newly introduces sw_stats >> to query slowpath traffic. Makes sense to me. >> > > I agree with Jiri. It is a bad idea to depend on ethtool for any of > this stuff.
The concern should not be that it is an ethtool api. In all previous discussions on this patchset and also my stats api patches, i have indicated that we have to move all stats in one place, so naturally, ethtool stats should move eventually to the stats api as a new nested netlink attribute. I think i called it IFLA_STATS_LINK_HW (or something like that)... and this nested attribute should provide the flexibility and extensibility of the current ethtool stats api. > Is there a way we can tag netlink stats instead > to indicate they are hardware or software? > We already have a use case with the tc where someone could get/set > hardware and/or software. > > cheers, > jamal
