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 23BE4A0597; Thu, 9 Apr 2020 17:22:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A4841C2F7; Thu, 9 Apr 2020 17:22:30 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id B78281C2F6; Thu, 9 Apr 2020 17:22:28 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0F25158023C; Thu, 9 Apr 2020 11:22:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 09 Apr 2020 11:22:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=jtKeta4VX7lG9sheWuEO1SQqFLmxTzOEFtughTfAzJU=; b=DTVbRtyjFhtF I1583myvICHdgwdM0dKThFQgeBSdymp1aHwq7wpeTT6QB6eqmIg7k9C4IbQ0wO1q wC4B59mwXVqKCqfQbVARM/NUvmnkbxiyo4BN5ragmpvkF2J7HQGYXp3e0l4piz0W xXmvcDSumZhRfCoPi2Egkc28+GEGa44= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=jtKeta4VX7lG9sheWuEO1SQqFLmxTzOEFtughTfAz JU=; b=upmiQqCNW7EOhXCtK94vMZyacPTPHuvXw2c3cm1SRaJp6YVGNJLjOpfuz 7N+5FpMC7cdw8u7G0B0GDqXj3Fsfxq6PZEOfaszBO7Odqku6HUu3C26zsLbMNnS9 JRDtJEH2NMu3VGGQo/OCKEB7MuYGmvfdiXowBtZ+YLE38f72E3BDHm1K/8wk33Ct L+0ihNFsjByONBCtFlW51eMSibPeiCdfwdnSVfedLdQVEtMrIWLTNRi1cKK8uCoS 4dlly3xomvcjBTg2TreUTarsCw/lQ5ei/sENP3cOofcRo0wc+7URXLzqxkZivJfJ ZpPAic48NppIXcKjzfky9aOW2kCIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgdekvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgepudenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 79C1D3280063; Thu, 9 Apr 2020 11:22:23 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , Lukasz Wojciechowski Cc: Anoob Joseph , Akhil Goyal , Declan Doherty , Aviad Yehezkel , Boris Pismenny , Radu Nicolau , Anoob Joseph , "dev@dpdk.org" , "stable@dpdk.org" Date: Thu, 09 Apr 2020 17:22:21 +0200 Message-ID: <2535618.Isy0gbHreE@thomas> In-Reply-To: <91240a63-76d0-508e-3071-b1e871c74294@partner.samsung.com> References: <20200312151654.7218-1-l.wojciechow@partner.samsung.com> <91240a63-76d0-508e-3071-b1e871c74294@partner.samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v2 01/13] security: fix verification of parameters 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" 09/04/2020 16:21, Lukasz Wojciechowski: > W dniu 09.04.2020 o 16:07, Lukasz Wojciechowski pisze: > > W dniu 09.04.2020 o 13:13, Bruce Richardson pisze: > >> On Thu, Apr 09, 2020 at 12:54:10PM +0200, Thomas Monjalon wrote: > >>> 09/04/2020 12:14, Bruce Richardson: > >>>> On Wed, Apr 08, 2020 at 07:51:35PM +0200, Thomas Monjalon wrote: > >>>>> 08/04/2020 17:49, Lukasz Wojciechowski: > >>>>>> Hi guys, > >>>>>> > >>>>>> I don't know what is the current status of "legacy" build using > >>>>>> gnumakes, so I added the new DEBUG flag to config just as it was > >>>>>> done in > >>>>>> other libs like eventdev. > >>>>>> Many guides still point config files as the one that should be > >>>>>> changed > >>>>>> in order to enable some features, so I thought I should add it > >>>>>> there. > >>>>>> > >>>>>> If I understand well the official build system now is the one > >>>>>> based on > >>>>>> using meson and ninja, however it hasn't got anything similar to the > >>>>>> gnamakefiles system, e.g. > >>>>>> in the meson.build file for libraries all the libraries have build > >>>>>> variable set to true and there are few ifs that check it, but as > >>>>>> it's > >>>>>> set to true all libraries build always. > >>>>>> And each library considered there defines RTE_LIBRTE_[LIBRARY_NAME]. > >>>>>> It's kind of weird. > >>>>>> > >>>>>> foreach l:libraries > >>>>>> * build = true** > >>>>>> * reason = '' # set if build == false to > >>>>>> explain why > >>>>>> ... > >>>>>> * if not build* > >>>>>> dpdk_libs_disabled += name > >>>>>> set_variable(name.underscorify() + > >>>>>> '_disable_reason', reason) > >>>>>> else > >>>>>> enabled_libs += name > >>>>>> *dpdk_conf.set('RTE_LIBRTE_' + name.to_upper(), 1)* > >>>>>> ... > >>>>>> > >>>>>> Have you think about reusing config files in meson configuration and > >>>>>> have a single point of configuration? Of course all meson flags can > >>>>>> overwrite the default config. > >>>>> This is on purpose. > >>>>> We are removing most of compile-time options with meson. > >>>>> > >>>>> I think we can use a global option for debug-specific code. > >>>>> Bruce, what do you recommend? > >>>>> > >>>> Meson has a built-in global debug setting which could be used. > >>>> However, > >>>> that may be too course-grained. If that is the case there are a > >>>> couple of > >>>> options: > >>>> > >>>> 1 Each library can have it's own debug flag defined, which is set on > >>>> the commandline in CFLAGS. Can be done right now - just reuse > >>>> any of the > >>>> debug variables in the existing make config files (stripping off > >>>> the > >>>> CONFIG_), e.g. CFLAGS=-DRTE_MALLOC_DEBUG > >>>> 2 Since that is perhaps not the most usable - though easiest to > >>>> implement - > >>>> we can look to add a general debug option (or couple of options) in > >>>> meson, e.g. debug_libs=, debug_drivers=, where each option takes > >>>> a list of > >>>> libs or drivers to pass the debug flags to. This will require a > >>>> little > >>>> work in the meson build infrastructure, but is not that hard. > >>>> The harder > >>>> part is standardizing the debug flags across all components. > >>>> > >>>> The advantage of #1 is that it works today and just needs some > >>>> documentation for each lib/driver what it's debug flags are. The > >>>> advantage > >>>> of #2 is more usability, but it requires a lot more work to > >>>> standardize > >>>> IMHO. > >>> In this case, we need a general option as the one already provided > >>> by meson. > >>> It means: "I am not in production, I want to see anything behaving > >>> wrong > >>> in the datapath." > >>> "Anything" means we don't need a per-library switch. > >>> And for the other needs (out of fast path), we have a new function: > >>> rte_log_can_log(mylogtype, RTE_LOG_DEBUG) > >>> > >> To use the general option in meson something like below is probably all > >> that is needed to flag the debug build to all components: > >> > >> diff --git a/config/meson.build b/config/meson.build > >> index 49482091d..b01cd1251 100644 > >> --- a/config/meson.build > >> +++ b/config/meson.build > >> @@ -176,6 +176,10 @@ endif > >> # add -include rte_config to cflags > >> add_project_arguments('-include', 'rte_config.h', language: 'c') > >> > >> +if get_option('debug') > >> + add_project_arguments('-DDEBUG', language: 'c') > >> +endif > >> + > > > > This will conflict with DEBUG define for log level. > Just to be more precise, the log level is defined as RTE_LOG_DEBUG, but > in few places you can find something like: > #define NTB_LOG(level, fmt, args...) \ > rte_log(RTE_LOG_ ## level, ntb_logtype, "%s(): " fmt "\n", \ > > __func__, ##args) > > and usage like this: > NTB_LOG(DEBUG, "Link is not up."); This is not a conflict. The compiler sees only RTE_LOG_DEBUG. Anyway the right name for the general flag should be RTE_DEBUG. > > How about adding similar define in library meson.build file? , e.g > > > > diff --git a/lib/librte_security/meson.build > > b/lib/librte_security/meson.build > > index 5679c8b5c..ee92483c5 100644 > > --- a/lib/librte_security/meson.build > > +++ b/lib/librte_security/meson.build > > @@ -4,3 +4,7 @@ > > sources = files('rte_security.c') > > headers = files('rte_security.h', 'rte_security_driver.h') > > deps += ['mempool', 'cryptodev'] > > + > > +if get_option('debug') > > + add_project_arguments('-DRTE_LIBRTE_SECURITY_DEBUG', language: 'c') > > +endif It can work yes. But it would be simpler to align on single debug flag.