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 AD79BC3F0 for ; Wed, 17 Jun 2015 13:17:13 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 17 Jun 2015 04:17:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,632,1427785200"; d="scan'208";a="589472348" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.21]) by orsmga003.jf.intel.com with SMTP; 17 Jun 2015 04:17:11 -0700 Received: by (sSMTP sendmail emulation); Wed, 17 Jun 2015 12:17:10 +0025 Date: Wed, 17 Jun 2015 12:17:09 +0100 From: Bruce Richardson To: Matthew Hall Message-ID: <20150617111709.GA6752@bricha3-MOBL3> References: <9092314.MoyqUJ5VU2@xps13> <20150617043654.GA10337@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150617043654.GA10337@mhcomputing.net> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 17 Jun 2015 11:17:14 -0000 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 proposal: > > 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 multiple apps > without having to rebuild it. It seems like it is also a bit ABI hostile > 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 impossible for > DPDK or just theorizing? > +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 compiler will be smart enough to make the check just once. If not, we can always do that in the C code by duplicating the hotpath code for with or without stats cases - again selectable at runtime. 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-time disabling should need to be provided. For example, any library that is keeping a track 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 any app. :-) Regards, /Bruce