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 19E10A0540; Tue, 14 Jul 2020 00:44:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 43DD01D64D; Tue, 14 Jul 2020 00:44:37 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 61A8D1D64C for ; Tue, 14 Jul 2020 00:44:35 +0200 (CEST) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200713224434euoutp02685c0d4cc108bb09484b0e75044ec1fd~hcULQ845y2706227062euoutp02M for ; Mon, 13 Jul 2020 22:44:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200713224434euoutp02685c0d4cc108bb09484b0e75044ec1fd~hcULQ845y2706227062euoutp02M DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1594680274; bh=+/CeIfajkFCEdoLi4nEOW2+RaFSgpce2ZHXiyM6CPrY=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=FRe1F9fpMXtCEGAE2WXSNxQUOR3BdHF+J9ypWLMcSBCTszq/m4WQexR2o3OTUnzjh gItN9XFRuCg5YC768HgAQmcAm2YkIkQ0Hyv0DEkxqPogK+qvHNx+cQ5Kbm5hs6okRJ EHC8IgYLtUdX+c3dEC8Rtv9ZO7l3EAS4Kx3kX1Zg= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20200713224433eucas1p12c7910fc3074b6389f75bb7ff3880465~hcUKd5DHj0298202982eucas1p1P; Mon, 13 Jul 2020 22:44:33 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id C0.4A.06456.1D3EC0F5; Mon, 13 Jul 2020 23:44:33 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200713224433eucas1p23b2c4730a14a64f9dfc3a66d42ada858~hcUJ0Bvfr1804318043eucas1p2M; Mon, 13 Jul 2020 22:44:33 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200713224433eusmtrp140d7f734fe359d26f5869652a93c4831~hcUJzeeog3275432754eusmtrp1H; Mon, 13 Jul 2020 22:44:33 +0000 (GMT) X-AuditID: cbfec7f2-7efff70000001938-d8-5f0ce3d1ee69 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 4C.2C.06314.1D3EC0F5; Mon, 13 Jul 2020 23:44:33 +0100 (BST) Received: from [106.210.88.70] (unknown [106.210.88.70]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20200713224432eusmtip11de998d869051212c06d63d3200e1774~hcUJM4DNy2517525175eusmtip1V; Mon, 13 Jul 2020 22:44:32 +0000 (GMT) To: Bruce Richardson , Thomas Monjalon Cc: dev@dpdk.org, david.marchand@redhat.com, Konstantin Ananyev From: Lukasz Wojciechowski Message-ID: <94db9764-2b26-a2e3-be1f-56905f4009a4@partner.samsung.com> Date: Tue, 14 Jul 2020 00:44:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200713090409.GA694@bricha3-MOBL.ger.corp.intel.com> Content-Transfer-Encoding: 8bit Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsWy7djPc7oXH/PEG7QtNLO4screYvuKLjaL d5+2M1m8/7OIxeLTgxMsDqwevxYsZfVYvOclk8exm9PYPd7vu8oWwBLFZZOSmpNZllqkb5fA lbHq2DOmgs8yFZd/drM3MPaIdzFycEgImEhMXJ7UxcjFISSwglFibvtkVgjnC6PE/mszGSGc z4wSy/Z0MncxcoJ1vJx6mAXEFhJYziixcXEhhP2WUeLBjEgQW1jASeLNzLtg9SICURIf9jeB 2cwCCRK/d/xlB7HZBGwljsz8ygpi8wq4Sez/eYAJxGYRUJXo65kIFhcViJNY/3I7E0SNoMTJ mU/A9nIKOEvMefKGHWKmvETz1tlQ88Ulbj2ZzwRytITAPHaJBQs3s0Ec7SKxfMtjdghbWOLV 8S1QtozE6ck9LBAN2xglrv7+yQjh7GeUuN67AqrKWuLwv99soABjFtCUWL9LHyLsKPF/4lEW SDjySdx4KwhxBJ/EpG3TmSHCvBIdbUIQ1XoST3umMsKs/bP2CcsERqVZSF6bheSdWUjemYWw dwEjyypG8dTS4tz01GLDvNRyveLE3OLSvHS95PzcTYzAFHP63/FPOxi/Xko6xCjAwajEwyvh zxMvxJpYVlyZe4hRgoNZSYTX6ezpOCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8xotexgoJpCeW pGanphakFsFkmTg4pRoYe8XMXVcVRxtb6sS8KJ7kUbbopKP9NOkJ1x8uVD7YejOwgrNR9KGV +wbvpv+3XHv2rcmw6tnC5PQtfXr9s1cyC+bN/ThJzfyA45novMjQ/NTGxvffZlqU9+3p7348 o/vctWM+ByXPMRnPiLwukmI/1W3Bs/3njZd4BhiIa0lyV05+cs+2+bGvEktxRqKhFnNRcSIA X8zWXy0DAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsVy+t/xu7oXH/PEGzT/5LW4screYvuKLjaL d5+2M1m8/7OIxeLTgxMsDqwevxYsZfVYvOclk8exm9PYPd7vu8oWwBKlZ1OUX1qSqpCRX1xi qxRtaGGkZ2hpoWdkYqlnaGwea2VkqqRvZ5OSmpNZllqkb5egl7Hq2DOmgs8yFZd/drM3MPaI dzFyckgImEi8nHqYpYuRi0NIYCmjxJltF9m6GDmAEjISHy4JQNQIS/y51sUGUfOaUWLTpm8s IAlhASeJNzPvMoPYIgJREovazrKC2MwCCRLPW6YxQjSsZpJYuPQpWAObgK3EkZlfwYp4Bdwk 9v88wARiswioSvT1TASLiwrESSzfMp8dokZQ4uTMJ2C9nALOEnOevGGHWGAmMW/zQ2YIW16i eetsKFtc4taT+UwTGIVmIWmfhaRlFpKWWUhaFjCyrGIUSS0tzk3PLTbUK07MLS7NS9dLzs/d xAiMq23Hfm7ewXhpY/AhRgEORiUeXgl/nngh1sSy4srcQ4wSHMxKIrxOZ0/HCfGmJFZWpRbl xxeV5qQWH2I0BXpuIrOUaHI+MObzSuINTQ3NLSwNzY3Njc0slMR5OwQOxggJpCeWpGanphak FsH0MXFwSjUwJpXKWK+28lTN6xAV1vrA+3ArX/XN7LdZ23yuss9KMvwmsezaxsee1+PTepgz 39bILd8xe90MWaPH68U3CCRN+bPQ4JUGj3ztA9s2k4shEstKnr0968JQFWMUcdJoqVDq/ZiK GwHcxipla2+wlQcumHPVa/7UGRxeMSmuSX9uvJGoa9n1Uea8EktxRqKhFnNRcSIAtObExcEC AAA= X-CMS-MailID: 20200713224433eucas1p23b2c4730a14a64f9dfc3a66d42ada858 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200709134846eucas1p193d963c3f21f0d5c4985024b6d015042 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200709134846eucas1p193d963c3f21f0d5c4985024b6d015042 References: <20200422214555.11837-1-l.wojciechow@partner.samsung.com> <20200709134823.9176-1-l.wojciechow@partner.samsung.com> <2283396.fTMGzKxhym@thomas> <20200713090409.GA694@bricha3-MOBL.ger.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH v3 0/4] introduce global 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" W dniu 13.07.2020 o 11:04, Bruce Richardson pisze: > On Sat, Jul 11, 2020 at 05:11:52PM +0200, Thomas Monjalon wrote: >> 09/07/2020 15:48, Lukasz Wojciechowski: >>> This set of patches introduces a global rte_debug flag for dpdk. >>> This will allow easy switch to debug build configuration using a single >>> flag. In the debug mode a RTE_DEBUG macro is defined to 1 >>> and for every enabled to be built library a RTE_DEBUG_{library name} >>> and for every enabled to be built driver >>> a RTE_DEBUG_{driver_class}_{driver_name} is also defined. >>> These macros can be used to place a debug code >>> inside #ifdef #endif clauses. >>> >>> The following requirements were discussed on the mailing list: >>> 1) The global debug flag is required to enable all the sanity checks >>> and validations that are normally not used due to performance reasons >>> >>> 2) The best option would be to have a single flag - not to introduce >>> too many build options >>> >>> 3) This option should be separated from meson "debug" option >>> (used for build with symbols) and can be called "rte_debug" >>> >>> 4) The currently existing DEBUG macros should not be replaced with >>> a RTE_DEBUG macro. This would allow to still enable them using >>> CFLAGS="-D..." to test a single module (library, driver). >> Please can we clarify this point? >> You mean not replacing driver macros with the global RTE_DEBUG? >> But we agree (next point) to replace existing macros? >> >>> 5) Currently existing options' names should be standardized >>> to RTE_DEBUG_{library/driver name}, so they can be automatically enabled >>> when rte_debug is set. Standardized names would allow easy usage >>> in other modules. >>> >>> 6) The debug functionality should be encapsulated in: >>> if (rte_log_can_log(...)) { >>> ... >>> } >>> for possibility to be filtered out in runtime. >>> >>> >>> Because of the hot discussion of v1 version of patches, I limit >>> the v2 version to mbuf library changes only, to see how it will impact >>> the performance with rte_log_can_log usage and to get opinions. >>> >>> v3 contains mbuf performance tests, which might help dpdk developers >>> community to decide if drop of performance related to rte_log_can_log >>> can be accepted. >>> >>> If agreement is reached, next steps would be to follow changes >>> in other libraries and drivers. >> If I understand well, it makes no sense to apply this v3, >> without having the rest of the code converted? >> > I'd nearly take the opposite view, that merging this patchset is a > pre-requisite to converting the rest of the code. By merging this now, it > allows others to work in parallel on any conversion they want to do, rather > than requiring it all to be part of the one patchset. > > On the other hand, it would be good to get more buy-in from maintainers > that this does meet their requirements at this point (and if not what could > be changed to make it meet them) > > Regards, > /Bruce I agree with Bruce. These patches are ready to apply. After they are introduced work can be parallelized and done for following libraries and drivers. However the mbuf library was chosen to verify performance of the solution. I published mbuf performance tests and the results for various compilation variants as a reply to former discussion, but there is no answer yet. The most interested person seemed to be Konstantin. Maybe we should wait for his opinion. -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciechow@partner.samsung.com