From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id DEAF8A0597
for <public@inbox.dpdk.org>; Thu, 9 Apr 2020 18:10:17 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id E1C7A1D171;
Thu, 9 Apr 2020 18:10:16 +0200 (CEST)
Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com
[210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 639E61D166
for <stable@dpdk.org>; Thu, 9 Apr 2020 18:10:14 +0200 (CEST)
Received: from eucas1p1.samsung.com (unknown [182.198.249.206])
by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id
20200409161013euoutp0251c0976a4dd3d42ac6707539cabc1b32~EMpvj_aus1117011170euoutp02W
for <stable@dpdk.org>; Thu, 9 Apr 2020 16:10:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com
20200409161013euoutp0251c0976a4dd3d42ac6707539cabc1b32~EMpvj_aus1117011170euoutp02W
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 <thomas@monjalon.net>, Bruce Richardson
<bruce.richardson@intel.com>
Cc: Anoob Joseph <anoobj@marvell.com>, Akhil Goyal <akhil.goyal@nxp.com>,
Declan Doherty <declan.doherty@intel.com>, Aviad Yehezkel
<aviadye@mellanox.com>, Boris Pismenny <borisp@mellanox.com>, Radu Nicolau
<radu.nicolau@intel.com>, Anoob Joseph <anoob.joseph@caviumnetworks.com>,
"dev@dpdk.org" <dev@dpdk.org>, "stable@dpdk.org" <stable@dpdk.org>
From: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Message-ID: <ec218c78-9936-9298-beda-bf0f73f20b7b@partner.samsung.com>
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>
<cecc0c0d-a676-4963-b46d-121f0584ed41@partner.samsung.com>
<91240a63-76d0-508e-3071-b1e871c74294@partner.samsung.com>
<CGME20200409152233eucas1p1aa0714336420aff9b3d0be026c86d178@eucas1p1.samsung.com>
<2535618.Isy0gbHreE@thomas>
Subject: Re: [dpdk-stable] [EXT] Re: [dpdk-dev] [PATCH v2 01/13] security:
fix verification of parameters
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
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 = '<unknown 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