On Fri, Jun 17, 2016 at 10:12 AM, Florian Fainelli <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 have also mentioned this before, the default api must provide accumulated (hw and sw) stats..., because this is the api that the user queries on an interface. For advanced debugging, people do want a break down and thats what traditionally ethtool has provided and the new stats api should eventually include support for ethtool like stats.
