[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJieiUhUSMJOLLM52P_0bDVtCFCVRVe0gEdLvwBCTgJKUQyE1g@mail.gmail.com>
Date: Fri, 8 Jul 2016 07:05:01 -0700
From: Roopa Prabhu <roopa@...ulusnetworks.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Anuradha Karuppiah <anuradhak@...ulusnetworks.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
Nogah Frankel <nogahf@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>,
Elad Raz <eladr@...lanox.com>,
Yotam Gigi <yotamg@...lanox.com>,
Or Gerlitz <ogerlitz@...lanox.com>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
John Linville <linville@...driver.com>,
Thomas Graf <tgraf@...g.ch>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
Scott Feldman <sfeldma@...il.com>, sd@...asysnail.net,
eranbe@...lanox.com, Alexei Starovoitov <ast@...mgrid.com>,
Eric Dumazet <edumazet@...gle.com>,
"hannes@...essinduktion.org" <hannes@...essinduktion.org>,
Florian Fainelli <f.fainelli@...il.com>,
David Ahern <dsa@...ulusnetworks.com>
Subject: Re: [patch net-next v5 0/4] return offloaded stats as default and
expose original sw stats
On Mon, Jun 27, 2016 at 6:11 AM, Jiri Pirko <jiri@...nulli.us> wrote:
> Mon, Jun 27, 2016 at 03:02:31PM CEST, roopa@...ulusnetworks.com wrote:
[snip]
>>
>>The point of the stats api is to bring all stats together.
>>ethtool stats are very valuable. so there is no point leaving them out.
>>they will be in here sooner or later.
>>
>>when there is already a discussion of moving ethtool to netlink,..i am not sure
>>I understand the hesitation on moving ethtool stats to netlink.
>
> It's not well defined. That's the issue. It's "debugfs"...
>
>
>>
>>>
>>>
>>> This patchset uses well defined values for slowpatch(/sw/cpu) stats.
>>> That is I believe the only way to do this.
>>>
>>
>>It seems to be your preferred way. I don't think it is the only way to
>>do it. It can very well be part of the nested
>>breakdown stats i am talking about.
>
> We are using existing well-defined structure. Very easy and clean.
sure, it is well-defined.
but my only point was the aggregate stats that the user or app cares
about is in your
so called already present 'well-defined structure'. everything
else...ie the breakdowns are purely for
debuggability and hence falls into the other bucket which you call
"debugfs" like.
splitting the kernel default interface stats into HW and SW is going
to confuse people
on the existing api and may introduce ambiguity for future stats is
all i am saying.
Powered by blists - more mailing lists