From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id A374B293B for ; Wed, 6 Apr 2016 14:16:02 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id u206so42796535wme.1 for ; Wed, 06 Apr 2016 05:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=iLykRV/6Hp/BvrFeLmDXlr2AxGEYhWTf70ZeYAh3td0=; b=bzBk3MA9bVd2Onm/tSaZBLy09Xn/r1T33olxOm9FwRBuar2wCoyUTUnJf9Mc92sfD3 Yk9ZZd151OO3XqjMB4FOuSiwNnT/vNx3d4wgBV5pHMHEnnPlR9y+hmxVk5ST1DTcovNR 48ishljZdX8NTMy9CKUNZJXfxLSoB/rVoTgxiUyp/NDiPYv266HP2WjwphSdsB2v8lUv GMt709XuAnz4hbcW7ClKATlLBGzLNijz/JrPi1Uv6bO5tUgTx65bpsb+ofVPabS9nCEd LAX4JPnnItG63qjh/lVajUL+BbdV2Btj2IAG8PO7dXFlSPgq3ciZVkHAsZr8bm8u9ebX LRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=iLykRV/6Hp/BvrFeLmDXlr2AxGEYhWTf70ZeYAh3td0=; b=hYwpZ91wcRqkQas1mToIQD3IdZyIxrAqe6O0osMdY94A2MIccYceUPVP8Zu8mjxKll oTyk3Gh7TH2spHit4m8AiRv2vqb2R1fLAt1Jvd48mtYYK7MqSox5E/QLtb1PhZVYOnHG Fw3564PwbOJilSKrUgVMBSS4zgqcYUO6fXJcGGoHEqrjY6YSI4Gn9C14OLVYjYe2M3U0 a6pZ2ohEFt12g2aRW8rGXKvckW5VQ/FIGrrAYtvDNskJyGa968N1Ta7ikbGbWRgRfBRw eQNft2buqf72ocEmgK3sv/mRB32eXulOYZC6PxSPkO/N2nxZ9RBnkIXGTEAYzouUJKQT ofzQ== X-Gm-Message-State: AD7BkJJFbFLI5TNFme/IGsYu1V4qcEZorkVcsxI2oy4j2yRqImfFeTVcX0rKwlWgtIzBRKRj X-Received: by 10.28.130.67 with SMTP id e64mr23769037wmd.6.1459944962487; Wed, 06 Apr 2016 05:16:02 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id d2sm2993008wjf.28.2016.04.06.05.16.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 05:16:01 -0700 (PDT) From: Thomas Monjalon To: "Van Haaren, Harry" Cc: "'David Harton (dharton)'" , dev@dpdk.org, "Tahhan, Maryam" , "olivier.matz@6wind.com" Date: Wed, 06 Apr 2016 14:14:23 +0200 Message-ID: <23174662.vdJtoqjRUU@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1459879089-3430-1-git-send-email-harry.van.haaren@intel.com> <27546869.TpcjJvEkXE@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] doc: announce xstats api change for 16.07 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:16:02 -0000 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. > The proposal is to make the API more flexible, see example: > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/31728/focus=32795 > > This more flexible API would allow other types of information about > statistics be retrieved too. OK I think I start to understand. > For now, the sent patch announces that the API/ABI may change, and we can > discuss details of API as development starts. 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 discussed on the mailing list. Given the previous explanations (and knowing you did good job on stats), I give my Acked-by: Thomas Monjalon