From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 04064C642 for ; Thu, 18 Jun 2015 15:25:36 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 18 Jun 2015 06:25:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,638,1427785200"; d="scan'208";a="745833315" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga002.fm.intel.com with ESMTP; 18 Jun 2015 06:25:34 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.201]) by IRSMSX152.ger.corp.intel.com ([169.254.6.90]) with mapi id 14.03.0224.002; Thu, 18 Jun 2015 14:25:33 +0100 From: "Dumitrescu, Cristian" To: Matthew Hall , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI Thread-Index: AQHQqLevzmGA0n3ChEeG3Of5+YSdSJ2yPO7A Date: Thu, 18 Jun 2015 13:25:33 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912632380E05@IRSMSX108.ger.corp.intel.com> References: <9092314.MoyqUJ5VU2@xps13> <20150617043654.GA10337@mhcomputing.net> In-Reply-To: <20150617043654.GA10337@mhcomputing.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI 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: Thu, 18 Jun 2015 13:25:38 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matthew Hall > Sent: Wednesday, June 17, 2015 5:37 AM > To: dev@dpdk.org > Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - > statistics - ABI >=20 > On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote: > > There were some debates about software statistics disabling. > > Should they be always on or possibly disabled when compiled? > > We need to take a decision shortly and discuss (or agree) this proposal= : > > http://dpdk.org/ml/archives/dev/2015-June/019461.html >=20 > This goes against the idea I have seen before that we should be moving > toward > a distro-friendly approach where one copy of DPDK can be used by multiple > apps > without having to rebuild it. It seems like it is also a bit ABI hostile > according to the below goals / discussions. Matthew, thanks for your input. As Thomas also mentions, it would be good t= o first read the proposal on the guideline (http://dpdk.org/ml/archives/dev= /2015-June/019461.html). In the guideline proposal, we are addressing the topic of preventing the AB= I changes due to library statistics support, it would be good to get your o= pinion on that, I am not sure you saw it. Given DPDK paramount focus on per= formance, I think probably provides the best solution for ABI compatibility= in this case. >=20 > Jemalloc is also very high-performance code and still manages to allow > enabling and disabling statistics at runtime. Are we sure it's impossible= for > DPDK or just theorizing? A performance improvement for one environment might still be an overkill fo= r DPDK run-time environment. Stats cannot be enabled/disabled at run-time without performance impact, as= it typically requires testing a persistent flag for incrementing the stats= counters, which requires a conditional branch instruction. Sometimes the b= ranches are predicted correctly, sometimes not, and in this case the CPU pi= peline needs to be flushed; typical branch misprediction cost is ~14 cycles= , which is important given a packet budget of ~200 cycles. When only a small number of branches are present in the (application + libr= ary) code, they are predicted correctly, so I am sure that for a simple tes= t application like l3fw the cost of run-time enabled stats is not visible. = The problem is that real applications are much more complex and they typica= lly have a lot of conditional branches, out of which the library stats test= is just one of them, so they cannot be all predicted correctly, hence the = cost of stats run-time enablement becomes very much visible. >=20 > > During the development of the release 2.0, there was an agreement to > keep > > ABI compatibility or to bring new ABI while keeping old one during one > release. > > In case it's not possible to have this transition, the (exceptional) br= eak > > should be acknowledged by several developers. >=20 > Personally to me it seems more important to preserve the ABI on patch > releases, like 2.X.Y going to 2.X.Z. But maybe I missed something? >=20 > > During the current development cycle for the release 2.1, the ABI quest= ion > > arises many times in different threads. >=20 > Most but not all of these examples point to a different issue which > sometimes > happens in libraries... often seen as "old-style" versus "new-style" C li= brary > interface. For example, in old-style like libpcap there are a lot of stru= cts, > both opaque and non-opaque, which the caller must allocate in order to ru= n > libpcap. >=20 > However new-style libraries such as libcurl usually just have init functi= ons > which initialize all the secret structs based on some defaults and some u= ser > parameters and hide the actual structs from the user. If you want to adju= st > some you call an adjuster function that modifies the actual secret struct > contents, with some enum saying what field to adjust, and the new value > you > want it to have. >=20 > If you want to keep a stable ABI for a non-stable library like DPDK, ther= e's a > good chance you must begin hiding all these weird device specific structs= all > over the DPDK from the user needing to directly allocate and modify them. > Otherwise the ABI breaks everytime you have to add adjustments, > extensions, > modifications to all these obscure special features. >=20 > Matthew.