[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160619105722.GA2022@nanopsycho.orion>
Date: Sun, 19 Jun 2016 12:57:22 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Florian Fainelli <f.fainelli@...il.com>,
David Ahern <dsa@...ulusnetworks.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
nogahf@...lanox.com, idosch@...lanox.com, eladr@...lanox.com,
yotamg@...lanox.com, ogerlitz@...lanox.com,
roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
linville@...driver.com, tgraf@...g.ch, gospo@...ulusnetworks.com,
sfeldma@...il.com, sd@...asysnail.net, eranbe@...lanox.com,
ast@...mgrid.com, edumazet@...gle.com, hannes@...essinduktion.org
Subject: Re: [patch net-next v4 0/4] return offloaded stats as default and
expose original sw stats
Sat, Jun 18, 2016 at 03:58:56PM CEST, jhs@...atatu.com wrote:
>On 16-06-18 04:00 AM, Jiri Pirko wrote:
>>Fri, Jun 17, 2016 at 07:12:22PM CEST, f.fainelli@...il.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.
Powered by blists - more mailing lists