From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DA851A046B for ; Wed, 26 Jun 2019 15:21:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9FDC220BD; Wed, 26 Jun 2019 15:21:31 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id EF2DA1E20 for ; Wed, 26 Jun 2019 15:21:29 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2019 06:21:29 -0700 X-IronPort-AV: E=Sophos;i="5.63,420,1557212400"; d="scan'208";a="155865739" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2019 06:21:27 -0700 Date: Wed, 26 Jun 2019 14:21:24 +0100 From: Bruce Richardson To: Slava Ovsiienko Cc: "dev@dpdk.org" , "bernard.iremonger@intel.com" , "ferruh.yigit@intel.com" Message-ID: <20190626132124.GD862@bricha3-MOBL.ger.corp.intel.com> References: <1561553317-16777-1-git-send-email-viacheslavo@mellanox.com> <20190626125732.GC862@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH] app/testpmd: add profiling for Rx/Tx burst routines X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Jun 26, 2019 at 01:19:24PM +0000, Slava Ovsiienko wrote: > Hi, Bruce > > Do you mean using "if (core_rx_cycle_enabled) {...}" instead of #ifdef ? > > No, I did not try runtime control settings. > Instead I compared performance with all RECORD_CORE_XX_CYCLES options enabled/disabled builds > and have seen the ~1-2% performance difference on my setups (mainly fwd txonly with retry). > So, ticks measuring is not free. > > With best regards, > Slava > Yes, I realise that measuring ticks is going to have a performance impact. However, what I was referring to was exactly the former - using an "if" rather than an "ifdef". I would hope with ticks disable using this option shows no perf impact, and we can reduce the use of build-time configs. /Bruce