Re: [patch net-next v4 0/4] return offloaded stats as default and expose original sw stats

Jiri Pirko
2016-06-19T10:57:26Z

Sat, Jun 18, 2016 at 03:58:56PM CEST, jhs@mojatatu.com wrote:
>On 16-06-18 04:00 AM, Jiri Pirko wrote:
>>Fri, Jun 17, 2016 at 07:12:22PM CEST, f.fainelli@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.