From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David Harton (dharton)" Subject: Re: [PATCH] doc: announce xstats api change for 16.07 Date: Wed, 6 Apr 2016 13:49:28 +0000 Message-ID: <9edf0e7ca1854e7cbb013359cb6423a8@XCH-RCD-016.cisco.com> References: <1459879089-3430-1-git-send-email-harry.van.haaren@intel.com> <27546869.TpcjJvEkXE@xps13> <23174662.vdJtoqjRUU@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Tahhan, Maryam" , "olivier.matz@6wind.com" To: Thomas Monjalon , "Van Haaren, Harry" Return-path: Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by dpdk.org (Postfix) with ESMTP id 01C1F2BFA for ; Wed, 6 Apr 2016 15:49:30 +0200 (CEST) In-Reply-To: <23174662.vdJtoqjRUU@xps13> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, April 06, 2016 8:14 AM > To: Van Haaren, Harry > Cc: David Harton (dharton) ; dev@dpdk.org; Tahhan, > Maryam ; olivier.matz@6wind.com > Subject: Re: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.07 >=20 > 2016-04-06 11:16, Van Haaren, Harry: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > The issue we are going to fix is that currently PMDs copy strings > > > > when retrieving > > > statistics, which causes unnecessary overhead. The implementation is > > > not decided yet, but using an int->value mapping seems logical. > > > > > I am not sure performance is so much critical when retrieving > statistics. > > > > In the previous discussion David was concerned about performance > > impact of string copies, are those concerns still present David? > > > > > The extended stats can be infinitely extended. So a string > > > identifier seems a lot more natural. > > > > I'm not suggesting that the string identifier is removed totally. > > > > > I do not agree to add a new numeric identifier in the API each time > > > a driver wants to report a specific statistic for debugging purpose. > > > > And I agree - the ints are just an index to xstats arrays, no eth-dev > wide enums here. Yes, I abandoned the idea of a set of stats ids. I can see where registrat= ion will be problematic and cumbersome to driver developers. > > The proposal is to make the API more flexible, see example: > > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/31728/focus=3D= 3 > > 2795 > > > > This more flexible API would allow other types of information about > > statistics be retrieved too. I have prototyped this. If there is interest/acceptance I can work on maki= ng an official patch to share back to the community. Using this method still gives the flexibility the current API desires while= giving the user the control to only obtain the counters. This of course a= ssumes that the counters per device are static but that seems a safe bet. >=20 > OK I think I start to understand. >=20 > > For now, the sent patch announces that the API/ABI may change, and we > > can discuss details of API as development starts. >=20 > This should not be the normal process. > It is important to understand what should be the changes to decide of > announcing or not a deprecation. > In the case of the mempool reworks, the patch have been sent and discusse= d > on the mailing list. > Given the previous explanations (and knowing you did good job on stats), = I > give my > Acked-by: Thomas Monjalon Thanks for considering this. Regards, Dave