Sat, Jun 18, 2016 at 03:58:56PM CEST, j...@mojatatu.com wrote: >On 16-06-18 04:00 AM, Jiri Pirko wrote: >>Fri, Jun 17, 2016 at 07:12:22PM CEST, f.faine...@gmail.com wrote: > >>>>Yep. And I believe that for offloaded forwarding, this tools should see >>>>hw counters, as they show what is going on in real. >>> >>>If your NIC is offloading packets today, these tools typically won't see >>>these stats, but ethtool -S likely will report what is going on under >>>the hood. >>> >>>Do we actually need to tell apart SW maintained from HW maintained >>>stats, or at the end all that matters is just, as DaveM pointed out, >>>getting the information, and in the case of an Ethernet switch, return >>>HW stats by default and supplement with SW stats whenever we have them, >>>all in the same namespace? >> > >In general it is extremely useful for debugging to be able to see them >separately. One API to unify them (and that API being netlink) is >the way to go. I dont know if you can ever obsolete ethtool if lots >of other utils are using it - but would be nice. >It is also useful to just get the sum of them - but user space can >take care of that. David A., whatever user space tools that depended >on ethtool should now be able to retrieve them via netlink, no? > >>I believe it is valuable for user to know stats for slow path >>(non-forwarded by ASIC). Also, it's just another rtnl attr. Easy. >> > >So Jiri, I see: >IFLA_SW_STATS64 should that be: IFLA_HW_STATS_LINK_64? >I think IFLA_STATS_LINK_64 should continue to send s/ware stats.
Well, we spent a lot of time to think about this. The problem with your approach is that existing apps don't see "real-stats" - hw stats. For example snmp daemon takes IFLA_STATS_LINK_64i, so it has to see HW stats there. In order to not break existing apps, we expose HW stats as default.
