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 695C5A0597; Thu, 9 Apr 2020 18:10:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8700A1D166; Thu, 9 Apr 2020 18:10:15 +0200 (CEST) Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by dpdk.org (Postfix) with ESMTP id 630CE1D155 for ; Thu, 9 Apr 2020 18:10:14 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20200409161013euoutp01552e1cd6f9953272e6dc2df0fab27241~EMpvj9Z1f2217222172euoutp01P for ; Thu, 9 Apr 2020 16:10:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200409161013euoutp01552e1cd6f9953272e6dc2df0fab27241~EMpvj9Z1f2217222172euoutp01P DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1586448613; bh=DDXfgogP7mcuvGXnpiUrBDOgs9cwR9Mn4GCEbjJG70I=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=iOFsqt4cDB8SyfoXNr1ZH1ShTUlxwQKWO+E/zC9dXXs+DUx7KDDpq59DkFa/J6E/2 vCKboFPbRCxJU4cNmUmQKdNjLz7jH0ElAg0XYA+QHYITW9Xh5qwdG+nJSP29dIw4lk yKY+P08bPGOlm3WnbeEUv8l2ZLLr4xPsfVA4OCfE= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20200409161013eucas1p13f4b7d06ca37a035f2dd7272bdcc9092~EMpvd2IeW0192101921eucas1p1W; Thu, 9 Apr 2020 16:10:13 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 6A.1B.60679.5E84F8E5; Thu, 9 Apr 2020 17:10:13 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200409161013eucas1p2630e7ab41902b37a331a973790e91623~EMpvHpm6c0543705437eucas1p20; Thu, 9 Apr 2020 16:10:13 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200409161013eusmtrp1224e4395a507f13cbeb24fe9b914132b~EMpvG_4YI0681306813eusmtrp1Z; Thu, 9 Apr 2020 16:10:13 +0000 (GMT) X-AuditID: cbfec7f4-0cbff7000001ed07-68-5e8f48e5e60b Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id C5.A5.08375.5E84F8E5; Thu, 9 Apr 2020 17:10:13 +0100 (BST) Received: from [106.210.88.70] (unknown [106.210.88.70]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200409161012eusmtip2d162f879b2bfc1b564f878751471af0d~EMpuJzlSK1446214462eusmtip2u; Thu, 9 Apr 2020 16:10:12 +0000 (GMT) To: Thomas Monjalon , Bruce Richardson Cc: Anoob Joseph , Akhil Goyal , Declan Doherty , Aviad Yehezkel , Boris Pismenny , Radu Nicolau , Anoob Joseph , "dev@dpdk.org" , "stable@dpdk.org" From: Lukasz Wojciechowski Message-ID: Date: Thu, 9 Apr 2020 18:10:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <2535618.Isy0gbHreE@thomas> Content-Transfer-Encoding: 8bit Content-Language: pl X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsWy7djP87pPPfrjDFo2alqsPzOP0eLU7Q/M Fsu2bGWy+DB5CaPFsR/t7BY3VtlbvHnQxGLx7tN2Jou2LgGLfx1/2C0+PTjB4sDtseFEP6vH rwVLWT0W73nJ5DF54UVmj2fTDzN5HLs5jd1j47sdTAHsUVw2Kak5mWWpRfp2CVwZjWcuMhcc Mqw4tWEKcwPjLvUuRk4OCQETiStvdjN1MXJxCAmsYJS4f7yPFcL5wiixqH8WG4TzmVGi62ID G0zL2TObmSESyxklnh1dAtX/llFizfqXzCBVwgKxElvnPgDrEBGIkti55yhYEbPAYyaJ10t+ s4Ak2ARsJY7M/MoKYvMKuElc2NnGCGKzCKhIzFnbwgRiiwINOvfoBlSNoMTJmU/AejkFNCTe TL4OZjMLyEs0b53NDGGLSNx41MIIskxC4B67xI0zj5gh7naRmHhyKZQtLPHq+BZ2CFtG4vTk HhaIhm2MEld//4Tq3s8ocb13BVSVtcThf7+B/uEAWqEpsX6XPkTYUaJl82wmkLCEAJ/EjbeC EEfwSUzaNp0ZIswr0dEmBFGtJ/G0ZyojzNo/a5+wTGBUmoXktVlI3pmF5J1ZCHsXMLKsYhRP LS3OTU8tNspLLdcrTswtLs1L10vOz93ECExhp/8d/7KDcdefpEOMAhyMSjy8Bgz9cUKsiWXF lbmHGCU4mJVEeL2beuOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8xovehkrJJCeWJKanZpakFoE k2Xi4JRqYFSVC/9Zv/bhZNH1f18HV7wxONMhfHPvZ89/CSVz/kpqnP0oqnAlUy9ksti7lj+v F9+xniP7fMbcbVVcfefir9bEiptk5WULP7lze/PLrG+yQr2cDz7yeJsfSLQruO4UKL6B+WhJ bqnFFek8Y4vgHX8CIktsD57znGm/qiHxgo1zgMiiUwdXMCuxFGckGmoxFxUnAgDS7bGXXQMA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsVy+t/xe7pPPfrjDNbuF7RYf2Yeo8Wp2x+Y LZZt2cpk8WHyEkaLYz/a2S1urLK3ePOgicXi3aftTBZtXQIW/zr+sFt8enCCxYHbY8OJflaP XwuWsnos3vOSyWPywovMHs+mH2byOHZzGrvHxnc7mALYo/RsivJLS1IVMvKLS2yVog0tjPQM LS30jEws9QyNzWOtjEyV9O1sUlJzMstSi/TtEvQyGs9cZC44ZFhxasMU5gbGXepdjJwcEgIm EmfPbGbuYuTiEBJYyihx9fg81i5GDqCEjMSHSwIQNcISf651sUHUvGaUePzuASNIQlggVuLL 8nlgtohAlMTXzZPAbGaBp0wS8/exg9hCAhuYJD49Ewax2QRsJY7M/MoKYvMKuElc2NkGVs8i oCIxZ20LE4gtCjSzv3k3I0SNoMTJmU9YQGxOAQ2JN5Ovs0DMN5OYt/khM4QtL9G8dTaULSJx 41EL4wRGoVlI2mchaZmFpGUWkpYFjCyrGEVSS4tz03OLDfWKE3OLS/PS9ZLzczcxAqN127Gf m3cwXtoYfIhRgINRiYfXgKE/Tog1say4MvcQowQHs5IIr3dTb5wQb0piZVVqUX58UWlOavEh RlOg5yYyS4km5wMTSV5JvKGpobmFpaG5sbmxmYWSOG+HwMEYIYH0xJLU7NTUgtQimD4mDk6p Bkb2vRdm9DooxTAUpMp/M1rblV4btef9xaY3n6f8b1nnvfyM4u54AX5zP8kFza3v7/45KsFf +qdwmWPT9zVBDP/W3Ap+zrP9zFNpbpkHR5Vvzgmebixm2PU4JXGWUtO5pWd/aiwO2cj++sDq hvSKv4Hajrf1mWO/6cx8Oc8wT/7qi0LjH++aDY4rsRRnJBpqMRcVJwIA2OBusewCAAA= X-CMS-MailID: 20200409161013eucas1p2630e7ab41902b37a331a973790e91623 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200409152233eucas1p1aa0714336420aff9b3d0be026c86d178 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200409152233eucas1p1aa0714336420aff9b3d0be026c86d178 References: <20200312151654.7218-1-l.wojciechow@partner.samsung.com> <91240a63-76d0-508e-3071-b1e871c74294@partner.samsung.com> <2535618.Isy0gbHreE@thomas> 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" W dniu 09.04.2020 o 17:22, Thomas Monjalon pisze: > 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. > Ok, I'll use RTE_DEBUG. @Bruce Is it ok, so that I would create a patch for meson.build? >>> 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. > In this set of patches I would only align the security and tests code to RTE_DEBUG. Changes in global configuration to use a single debug flag should be done in separate set of patches. > -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciechow@partner.samsung.com