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 E1F30A0528; Thu, 9 Jul 2020 16:09:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EF97F1E958; Thu, 9 Jul 2020 16:09:20 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 9FBD91E906 for ; Thu, 9 Jul 2020 16:09:19 +0200 (CEST) IronPort-SDR: j8RWoXIwnErqQYmkVgkXFHjZfmBXntjbjsbReb9TXBqEQrIL/5G3YOd5E3wSTLkAD3FAXMEIiU 1kt3nuECrvfw== X-IronPort-AV: E=McAfee;i="6000,8403,9676"; a="136222501" X-IronPort-AV: E=Sophos;i="5.75,331,1589266800"; d="scan'208";a="136222501" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2020 07:09:18 -0700 IronPort-SDR: FBUAyCAZ/cfWLrPrhv9Y2rmfu/AedJPVOjx7wUpnGzZSlU3QRrx2yo+9CSrSz4DPd6j7/we9qa Uq/Q3MomlX4w== X-IronPort-AV: E=Sophos;i="5.75,331,1589266800"; d="scan'208";a="306444614" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.217.86]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Jul 2020 07:09:17 -0700 Date: Thu, 9 Jul 2020 15:09:14 +0100 From: Bruce Richardson To: Lukasz Wojciechowski Cc: Thomas Monjalon , dev@dpdk.org Message-ID: <20200709140914.GA680@bricha3-MOBL.ger.corp.intel.com> References: <20200417215739.23180-1-l.wojciechow@partner.samsung.com> <20200422214555.11837-1-l.wojciechow@partner.samsung.com> <20200422214555.11837-2-l.wojciechow@partner.samsung.com> <20200626165630.GA564@bricha3-MOBL.ger.corp.intel.com> <1f900349-6701-d355-9084-c97cf5dccb75@partner.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1f900349-6701-d355-9084-c97cf5dccb75@partner.samsung.com> Subject: Re: [dpdk-dev] [PATCH v2 1/3] config: introduce global rte debug flag 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 Thu, Jul 09, 2020 at 03:51:25PM +0200, Lukasz Wojciechowski wrote: > > W dniu 26.06.2020 o 18:56, Bruce Richardson pisze: > > On Wed, Apr 22, 2020 at 11:45:53PM +0200, Lukasz Wojciechowski wrote: > >> A new boolean meson build flag is introduced with this patch: rte_debug. > >> To enable this option add -Drte_debug=true to the meson configure command. > >> > >> By enabling this flag the globaly defined macro RTE_DEBUG becomes > >> defined. It should be used for enabling debug code in all dpdk project > >> components. Using this flag allows to make additional checks or tests > >> and provide additional logs even in performance sensitive parts of code. > >> > >> The flag is disabled by default. > >> > >> Additionally for all enabled to be built libraries > >> a RTE_DEBUG_{library name} is defined and assigned a value 1. > >> This standardize names of library specific debug macros. Those can > >> be used also without rte_debug option by using CFLAGS="-D..." build > >> parameter. > >> > >> Code put inside RTE_DEBUG* #ifdef sections should be also put inside > >> if (rte_log_can_log(...)) condition to allow run-time filtering of > >> sanity checks, validations, logs and dumps when using rte_debug option. > >> > >> Libraries will be adjusted to the change in separate patches. > >> > >> Suggested-by: Bruce Richardson > >> Signed-off-by: Lukasz Wojciechowski > > The drivers are missing debug flag options, which probably need to be > > defined as _ e.g. RTE_DEBUG_NET_I40E, > > RTE_DEBUG_EVENT_SW, etc. > I added also flags for drivers constructed as you suggested (see v3). > It might however be a bit tricky to differentiate library debug flags > form drivers, e.g. > RTE_DEBUG_MEMPOOL (library) vs RTE_DEBUG_MEMPOOL_DPAA (driver). > > If there is a need the macro names can be changed by adding _LIB_ or _DRV_. > What do you think? I don't think DRV is needed for the drivers, though perhaps LIB (or RTE) could be added for the libs. I actually think that mempool is the only case where we might have any confusion, for other device classes the library names tend to have "dev" on the end, e.g. cryptodev, rawdev etc. So overall, I'd suggest it's not a problem, but if you want modify the lib one. /Bruce