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 0B0F9A0588; Wed, 1 Apr 2020 18:46:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A41591BFA6; Wed, 1 Apr 2020 18:46:14 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id C9FB01BF4F for ; Wed, 1 Apr 2020 18:46:13 +0200 (CEST) IronPort-SDR: EHxUcwA8STn2wtjzoO84DxZjubCT1RUwEek8w+QgHf+milH5Qd0ODKB6OBs84OqGaMvY9HzQ+Y J86HLMkNP6DA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2020 09:46:11 -0700 IronPort-SDR: YiVaXX61+z8l5vNZB09XG9HHyP2bJ7X1dgFEVx1pVutd9QfWuVpTsBqfq/PKjR1fQO6QAGNmFM cCV9Zx6BE9HA== X-IronPort-AV: E=Sophos;i="5.72,332,1580803200"; d="scan'208";a="422789146" Received: from bricha3-mobl.ger.corp.intel.com ([10.212.65.4]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 01 Apr 2020 09:46:08 -0700 Date: Wed, 1 Apr 2020 17:46:04 +0100 From: Bruce Richardson To: Jerin Jacob Cc: David Marchand , Jerin Jacob Kollanukkaran , Thomas Monjalon , dev , Mattias =?iso-8859-1?Q?R=F6nnblom?= , Sunil Kumar Kori , "Yigit, Ferruh" , Andrew Rybchenko , Declan Doherty , Olivier Matz , Neil Horman , Ray Kinsella Message-ID: <20200401164604.GB152@bricha3-MOBL.ger.corp.intel.com> References: <20200325211603.240288-1-jerinj@marvell.com> <20200329144342.1543749-1-jerinj@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3 00/33] DPDK Trace support 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, Apr 01, 2020 at 09:55:20PM +0530, Jerin Jacob wrote: > On Wed, Apr 1, 2020 at 7:42 PM David Marchand wrote: > > > > On Wed, Apr 1, 2020 at 12:05 PM Jerin Jacob wrote: > > > On Wed, Apr 1, 2020 at 1:49 PM David Marchand wrote: > > > > - Regardless of the trace framework, the ALLOW_EXPERIMENTAL_API flag > > > > gates access to APIs so that external users are aware of their status. > > > > I have been considering setting this flag unconditionally for internal > > > > users in the top Makefile/meson for app/ lib/ and drivers/. > > > > I could look at this and prepare a patch about this, but this is not > > > > enough here. > > > > > > It makes sense to me. Let me know when you are planning to send that patch, > > > I will rebase this series on top of that. > > > > Feel free to take over, thanks. > > OK. > > > > > > > > > > > If you don't have time then I can send the patch too. > > > I assume the patch content will be: > > > 1) Removing experimental API from app, lib, drivers, examples with > > > make and meson > > > 2) Have it enabled at the global level. > > > > examples are a special case as they can be compiled out of the dpdk sources. > > This is why I excluded them of the list in my mail before. > > There are a lot of examples already that have ALLOW_EXPERIMENTAL_API. > What is the issue in enabling ALLOW_EXPERIMENTAL_API in the in tree > example application? > > > > > > > > > Since the trace changes in the "inline" functions of the specific > > > library already > > > disabled under _compile time_ RTE_ENABLE_TRACE_DP flag and > > > it is using RTE_TRACE_POINT_DP() to define the trace unlike slow path > > > trace like RTE_TRACE_POINT(). > > > > Ah indeed. > > Note: RTE_ENABLE_TRACE_DP is not plugged with meson. > > If you see the " eal: define the public API for trace support" patch, > I have updated rte_config.h for meson likewise for other configuration > such log for DP. > Would you like to have a meson option? and update in meson_options.txt. > > I don't have a strong opinion on either way? Bruce ,any thoughts? > Since it's likely that developers will be wanting to switch this option on and off, I think an explicit option rather than hard-coded constant should be the way to go. However, an alternative might be to add in the DP tracing for debug builds but not for others. This would save a build option, but may be more restrictive, since debug builds can also be optimized ones. /Bruce