[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <576553A0.2060504@mojatatu.com>
Date: Sat, 18 Jun 2016 09:58:56 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jiri Pirko <jiri@...nulli.us>,
Florian Fainelli <f.fainelli@...il.com>
Cc: 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
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.
cheers,
jamal
Powered by blists - more mailing lists