Fri, Jun 17, 2016 at 07:12:22PM CEST, f.faine...@gmail.com wrote: >On 06/17/2016 08:42 AM, Jiri Pirko wrote: >> Fri, Jun 17, 2016 at 05:35:53PM CEST, d...@cumulusnetworks.com wrote: >>> On 6/17/16 8:54 AM, Jamal Hadi Salim 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. Is there a way we can tag netlink stats instead >>>> to indicate they are hardware or software? >>> >>> Right, old API but the key here is that low level h/w stats are returned by >>> a >>> different API. >>> >>> By default ip, ifconfig, snmpd, etc all continue to get traditional S/W >>> stats >>> - counters as seen by the CPU. >> >> 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?
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.
