From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id A567EC72E for ; Thu, 18 Jun 2015 18:32:29 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 18 Jun 2015 09:32:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,638,1427785200"; d="scan'208";a="713389979" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 18 Jun 2015 09:32:26 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.201]) by IRSMSX101.ger.corp.intel.com ([169.254.1.201]) with mapi id 14.03.0224.002; Thu, 18 Jun 2015 17:32:25 +0100 From: "Dumitrescu, Cristian" To: "Richardson, Bruce" , Matthew Hall Thread-Topic: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI Thread-Index: AQHQqO89zmGA0n3ChEeG3Of5+YSdSJ2yQrzw Date: Thu, 18 Jun 2015 16:32:24 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912632380FBB@IRSMSX108.ger.corp.intel.com> References: <9092314.MoyqUJ5VU2@xps13> <20150617043654.GA10337@mhcomputing.net> <20150617111709.GA6752@bricha3-MOBL3> In-Reply-To: <20150617111709.GA6752@bricha3-MOBL3> 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 Cc: "dev@dpdk.org" 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 16:32:30 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Wednesday, June 17, 2015 12:17 PM > To: Matthew Hall > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - > statistics - ABI >=20 > On Tue, Jun 16, 2015 at 09:36:54PM -0700, Matthew Hall wrote: > > 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 propos= al: > > > http://dpdk.org/ml/archives/dev/2015-June/019461.html > > > > 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 multip= le > apps > > without having to rebuild it. It seems like it is also a bit ABI hostil= e > > according to the below goals / discussions. > > > > Jemalloc is also very high-performance code and still manages to allow > > enabling and disabling statistics at runtime. Are we sure it's impossib= le for > > DPDK or just theorizing? > > >=20 > +1 to this. I think that any compile-time option to disable stats should = only > be used when we have a proven performance issue with just disabling them > at runtime. > I would assume that apps do not switch on or off stats multiple times per > second, > so any code branches to track stats or not would be entirely predictable = in > the > code - since they always go one way. Therefore, when disabledi, we should > be looking > at a very minimal overhead per stat. If there are lots of checks for the = same > value in the one path, i.e. lots of stats in a hot path, hopefully the co= mpiler > will be smart enough to make the check just once. If not, we can always d= o > that in the C code by duplicating the hotpath code for with or without st= ats > cases - > again selectable at runtime. >=20 I see where you're coming from, but reality is you cannot guarantee that th= e few conditional branches in the library are going to be predicted correct= ly simply because the application and the other libraries used by the app h= ave an unknown number of conditional branches themselves. For complex apps,= the total number of conditional branches is large and the more there are, = the lesser probability of such a branch being predicted correctly is. I agr= ee that for test apps like l3fwd with just a few branches the probability t= o have library branches being predicted correctly is high, but for me is an= incorrect proof point. The cost of ~14 cycles per branch misprediction is = important for DPDK packet budgets. Since we don't control the application, I am feeling very uncomfortable wit= h generic statements about how application is likely to execute and the imp= act of library conditional branches over the application should be. To me, = they sound like we are willing to take chances, and to me this is not the r= ight decision. In my opinion, the right decision for a significant framewor= k like DPDK is to keep all options open for the apps: keep counters always = enabled, keep counters always disabled, keep counters enabled first and dis= abled later. I suggest we should move the focus from WHY arguments like: "I= don't think anybody will ever need this this" to the HOW part of making su= re that technical solution we pick is correct and keeps all options open. I think stats are not always equivalent to incrementing a counter. In the g= uideline proposal, I am providing several examples of more complex statisti= cs logic that is more than just inc one counter. As an extreme case, think = about the case where the metric to compute requires complex math like predi= ction of next packet arrival time based on recent history, etc. When defini= ng a policy, we should consider a broad spectrum of metrics, not just n_pkt= s_in. > Also, there is also the case where the stats tracking itself is such low > overhead > that its not worth disabling. In that case, neither runtime nor compile-t= ime > disabling > should need to be provided. For example, any library that is keeping a tr= ack > of > bursts of packets should not need to have that stat disable option - one > increment > or addition per burst of (32) packets is not going to seriously affect an= y app. :- > ) >=20 > Regards, > /Bruce