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 003D3A0528; Thu, 9 Jul 2020 16:09:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D1C571E965; Thu, 9 Jul 2020 16:09:40 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 555CA1E965 for ; Thu, 9 Jul 2020 16:09:39 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200709140938euoutp02d4f4aa1cdaac1e385d1e02797a19a33f~gGtbrvoTA2219722197euoutp02a; Thu, 9 Jul 2020 14:09:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200709140938euoutp02d4f4aa1cdaac1e385d1e02797a19a33f~gGtbrvoTA2219722197euoutp02a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1594303778; bh=6jgo3dhK0qLlCt+2bVRFnaXv37GF9yTm4jLG01lNTZQ=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=Be24MnoVP9hfLuynoD5cWKL+usAfg0KPINGTqLRmgsgc0OIFtrLg9Z2NTh+Fjr1ns da/9kkSABjUbi4YTNZD7KcWxtehi7yRmvb8K4bCz55S8JLy+OuNhZ5mWcysS8IsMia yvd7UXgTg/wCOY01kT9MHUIOWcZ4t42DSQwr3fT4= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200709140938eucas1p29a0ad0b3a00469e2ae19d5ea1f724bcd~gGtbiGCKe2499124991eucas1p2i; Thu, 9 Jul 2020 14:09:38 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id 33.29.06456.225270F5; Thu, 9 Jul 2020 15:09:38 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200709140937eucas1p2a49b185771f1ef75069399e0ec7c98ad~gGtbABqmB2499624996eucas1p2c; Thu, 9 Jul 2020 14:09:37 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20200709140937eusmtrp2b34d5edac01d85a95cb0b46c342c0bde~gGta_lYsW1695816958eusmtrp28; Thu, 9 Jul 2020 14:09:37 +0000 (GMT) X-AuditID: cbfec7f2-809ff70000001938-1d-5f0725227574 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 90.52.06314.125270F5; Thu, 9 Jul 2020 15:09:37 +0100 (BST) Received: from [106.210.88.70] (unknown [106.210.88.70]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20200709140932eusmtip103935d3731bdd119e0b1c9061d414f16~gGtWSzwSz3154831548eusmtip1N; Thu, 9 Jul 2020 14:09:32 +0000 (GMT) To: Thomas Monjalon , "Richardson, Bruce" , "Ananyev, Konstantin" Cc: "Dumitrescu, Cristian" , Igor Russkikh , Pavel Belous , "Lu, Wenzhuo" , Marcin Wojtas , Michal Krawczyk , Guy Tzalik , Evgeny Schemeilin , Igor Chauskin , John Daley , Hyong Youb Kim , "Zhang, Qi Z" , "Wang, Xiao W" , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , "Wei Hu (Xavier)" , "Min Hu (Connor)" , Yisen Zhuang , "Xing, Beilei" , "Wu, Jingjing" , "Yang, Qiming" , Rasesh Mody , Shahed Shaikh , "Singh, Jasvinder" , Maxime Coquelin , "Wang, Zhihong" , "Ye, Xiaolong" , Yong Wang , "Yigit, Ferruh" , Andrew Rybchenko , Olivier Matz , "dev@dpdk.org" From: Lukasz Wojciechowski Message-ID: <41ec8e6b-ed2d-7ddb-d55c-cdbe06ba0063@partner.samsung.com> Date: Thu, 9 Jul 2020 16:09: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: <2172874.ECZNHGQPT7@thomas> Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA2WTb0xTZxTGfe+9vS3Vumth4QyWGJrq2BZAgsveZbjNbSF3miWOLDNboqzo DZDRQlpwOrONOPxDK9ExEAGFWgSxbkPUFhhgY9EyQAwwScHRoAKDCkWFIRMKrO1tE5Z9+53z Puc85/nwikjprDBMlKbK4tQqRbqMFlNm2/M7UbINwqRNN9rF+H6hg8a6J7kE7je+i6tynyFc MJRD4KnpegLf7Z2g8GBLpxDn2h7Q2Pp0HOH8W3YKl1UWC/ByRTqeto4JcYl+BuHm+d8p/Nht oLAtr5nCVdPDJP5j/JYAmw7VEXjmeCIuvnyCxoWNDQhPmg0kbquvFuDp+54p0+1FhIcdFxG2 jLUKsXvyDXzjqJbElcZOGs//fJ7CV3sKCOzKy6Pek7M9JwYRW9OtFbBdF/oFbOFCnYCd11cJ 2NybLgFb2ewk2J/O9ZCsbeCUkH18vY9mndcy2Usj/9DsVIWL3iH5Qhy/l0tP28epY975Upx6 saaXzlw8unp/9Z2nwhzUf1WsRUEiYDZDrc6ItEgskjI1CM40HfYXfyMwXTlH8MUMgqLhcmFg pPH0JMU/XEDwTHvKP+JC0No45FMFM7vg9EiHTxXCFCF45DD7VCRjFYP2xz6fima2wM2SWYGX JUwCjDrmCS9TjBxOTtiRl19kdkOts57gNeugvWSE8nIQEwlLzmOkl0nmM5gY/4vgORTujVT4 DgemRAw5Z40kf/iHUPBnHcFzMDxqu+YP9DIsNwYGzAj6Fp4jvrAgsOfX+FVvQ+vSAs3zVrDe a/FsFXl4LfS71vHOa6HAXOxvS+DYESmvjobR40Uo4OX+hQ8ADAumwWHhSRRRuiJb6Yo8pSvy 8LwefjCVkaUeB5J5FWp/i+HbiTBlKSX/K/FyJBw+c1bI82aw6Q/RPEdAoe6Bv/8WtMzN+VfG g12XGnC13D1C/l/+CnQ0nyf16AUjCuWyNcoUThOr4r6O1iiUmmxVSvSeDOUV5PmAnUtt0w1o tjfZihgRkq2RNCzTSVKBYp/mgNKK5J5NDy9f6kZhlCpDxclCJO93de6WSvYqDnzDqTOS1Nnp nMaKwkWULFQSZ3DukjIpiizuK47L5NSBV0IUFJaDNC81TSxEGbYlO3RdCfljxhFdyJY85aao Rfuqg/vl3+7Qf7R9TXzwx9djsspyJBsGPv/kYPLQxkjiU63716SIxKiEDrt6Mq379TbxxqbV cTtpQ8938tuxzYqdH4SvGvj+IZtJrK/e2lP4hC6XKW1xkcuj5dv7Ei2J7rk3ZXvmqtuN4TJK k6qIfY1UaxT/AuXrarOIBAAA X-Brightmail-Tracker: H4sIAAAAAAAAA2WTe0yTZxSH9363tsRunwXjGzbD7LrF3eoKQk8XYJsxy+cfmg13ideuwS/Q jLakX+umyRICuEGdUYRVLotlQOsoLhFppSzgsBN0qyTCQJyRrB1dhADq6lgnoF1LXUKy/56T 8/zOSU7eV0zKxph0sd5o4c1GXYmcSaECjy5PvLr+eZH2NW+nAoJ1EwwcuVdJwA33G+Cs/BvB id/KCLgT6SZgdGSGglt9ARFUDoYY8P85heDowDgFTa0naYg5SiDivy2Chub7CHoXrlBwd6mF gsHqXgqckUkSfpkaoMFb3knA/S8L4OTZYwzU9fgQzJ5vIeFyt4uGSDCe8l59iGByoh3BD7d/ FMHSbDZc/MJGQqs7wMDCmTYKuoZPEDBXXU29qeCGj91C3LfXbDQ3dPoGzdUtdtLcQrOT5iov zdFca+80wdV+M0xyg7/aRdzdC2MMN+0p5TrC/zDcHccc8450lzLXbLJa+GeLTYIlT75bBZlK lQaUmZs0SlWWeu/rmdnyjfm5+/kS/QHevDH/I2XxTCREl34elXw6GbrOlKFRl8SGJGLMbsI9 9bOUDaWIZawTYcdALF6I441n8L0RNumk4qXrNibpzCD89byXSjRS2b24PvzzcjiN/QrhcffN 5YJkr6bgfucFOhlpJ/Csy4ESEYbNw5ca5ukES9m38R8TC0SCKVaBj8+MLztr2H34tMchSjqr 8U8N4eV1EnYDfjRdRSaYZD/A3VU1dJLX4pthB3EcrW5cEWlcoTWu0JKcg091hcgkZ+AKb9Nj LsDf25dEjfELkOwL2HVY/n8lB1fP9zFJXo/rjoRESdbgvmj0sZOPQ/Za1IxWuVEabxUMRQZB pRR0BsFqLFIWmgznUPwZnx980OVDI507/IgVI/kqqS/GaGW07oBw0OBHiviY3892XEPplNFk 5OVp0s1DgX0y6X7dwUO82aQ1W0t4wY+y47erIdPXFJriH8Ro0aqyVWrQqNRZ6qwckK+VVrEX 98jYIp2F/5jnS3nzfzlCLEkvQxX4xUhGsNAzcPjUczXrnDXtfVGsF895CgqGzLGw1rPO9NRR 5tzi021t+mDTkN5a+0nGzvINikObc+1qj3Qs+t62h0FsD/XsKX+lPnPL1I6W7578cLsb+R60 928dD1XkOcknrvhSrGmpgZffd/Uyi5/FRv9S5KAtuzveOqN5t5+VU0KxTvUSaRZ0/wKYAoMk 6AMAAA== X-CMS-MailID: 20200709140937eucas1p2a49b185771f1ef75069399e0ec7c98ad X-Msg-Generator: CA X-RootMTR: 20200422122429eucas1p12cda205eb48b0aeb0f902c32abd5284e X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200422122429eucas1p12cda205eb48b0aeb0f902c32abd5284e References: <20200417215739.23180-1-l.wojciechow@partner.samsung.com> <26026576.gRfpFWEtPU@thomas> <2172874.ECZNHGQPT7@thomas> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v1 03/17] ethdev: replace library debug flag with global one 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 22.04.2020 o 14:24, Thomas Monjalon pisze: > 22/04/2020 13:29, Ananyev, Konstantin: >>> 22/04/2020 12:55, Bruce Richardson: >>>> On Wed, Apr 22, 2020 at 12:41:49PM +0200, Lukasz Wojciechowski wrote: >>>>> W dniu 21.04.2020 o 23:38, Thomas Monjalon pisze: >>>>>> 21/04/2020 22:58, Lukasz Wojciechowski: >>>>>>> W dniu 21.04.2020 o 02:32, Ananyev, Konstantin pisze: >>>>>>>>>>>>>>>> I am agree with Cristian concern here: that patch removes ability to >>>>>>>>>>>>>>>> enable/disable debug on particular library/PMD. If the purpose is to >>>>>>>>>>>>>>>> minimize number of config compile options, I wonder can't it be done >>>>>>>>>>>>>>>> in a slightly different way: 1. introduce gloabal RTE_DEBUG 2. keep >>>>>>>>>>>>>>>> actual .[c,h] files intact 3. In actual librte_xxx/meson.build file >>>>>>>>>>>>>>>> check if RTE_DEBUG is enabled, If yes, then enable particular debug >>>>>>>>>>>>>>>> flag for these libs. Something like: If dpdk_conf.get('RTE_DEBUG') == >>>>>>>>>>>>>>>> true dpdk_conf.set('RTE_LIBRTE_XXX_DEBUG ', 1) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> defines that are used by multiple libs, probably can be set in upper >>>>>>>>>>>>>>>> layer meson.build. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That way will have global 'debug' flag, but users will still have an >>>>>>>>>>>>>>>> ability to enable/disable debug flags on a per lib basis via >>>>>>>>>>>>>>>> CFLAGS="-D..." >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Konstantin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That seems a reasonable idea to me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, in this case, we don't need the RTE_DEBUG flag at all, we can >>>>>>>>>>>>>>> either: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * allow each component meson.build file define its own flags after >>>>>>>>>>>>>>> checking get_option('debug') * have lib/meson.build and >>>>>>>>>>>>>>> drivers/meson.build automatically define a specific define for each >>>>>>>>>>>>>>> library or driver to standardize the naming. [This would save anyone >>>>>>>>>>>>>>> working on it from having to lookup what the define was, since it's >>>>>>>>>>>>>>> always e.g. RTE_DEBUG_ + library-base-name, e.g. RTE_DEBUG_LPM, >>>>>>>>>>>>>>> RTE_DEBUG_SCHED etc] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Theoretically we can also do both, have the standard ones defined and >>>>>>>>>>>>>>> then allow a component to provide extra flags itself if so desired. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Bruce >>>>>>>>>>>>>> OK, so let's summarize how the patches should be redo: * usage of global >>>>>>>>>>>>>> "debug" flag for meson build stays * we standardize names of debug flags >>>>>>>>>>>>>> in the components to RTE_DEBUG_ + components name * debug flag enables al >>>>>>>>>>>>>> the RTE_DEBUG_... flags >>>>>>>>>>>>>> >>>>>>>>>>>>>> This allow to easily use both: * the debug flag - to enable all debugs * >>>>>>>>>>>>>> or define manually RTE_DEBUG+component name, just for debug from a single >>>>>>>>>>>>>> component >>>>>>>>>>>>>> >>>>>>>>>>>>>> I like Bruce's idea of adding it to the lib/meson.build and >>>>>>>>>>>>>> drivers/meson.build. This way they will be added to dpdk_conf meson >>>>>>>>>>>>>> object and written then later to rte_build_config.h before compilation >>>>>>>>>>>>>> stage. All the other modules will be able to use these flags. >>>>>>>>>>>>>> >>>>>>>>>>>>> Sounds good to me (obviously!), but I'd like other feedback to ensure >>>>>>>>>>>>> others are ok with this before you spend too much effort implementing it. >>>>>>>>>>>>> >>>>>>>>>>>>> For the drivers, the flag probably needs to include the category as well as >>>>>>>>>>>>> the name, e.g. RTE_DEBUG_NET_IXGBE, RTE_DEBUG_RAW_IOAT, to avoid possible >>>>>>>>>>>>> name confusion. Those flags can then be checked inside individual >>>>>>>>>>>>> meson.build files to enable other debug flags if necessary e.g. in ixgbe, >>>>>>>>>>>>> you could theoretically do: >>>>>>>>>>>>> >>>>>>>>>>>>> if dpdk_conf.has('RTE_DEBUG_NET_IXGBE') >>>>>>>>>>>>> cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_RX' >>>>>>>>>>>>> cflags += '-DRTE_LIBRTE_IXGBE_DEBUG_TX' >>>>>>>>>>>>> ... >>>>>>>>>>>>> endif >>>>>>>>>>>>> >>>>>>>>>>>>> to enable more fine-grained control if so desired, and to maintain >>>>>>>>>>>>> compatibility with existing defines, again if so desired. >>>>>>>>>>>> Nak the nak from Cristian. >>>>>>>>>>>> >>>>>>>>>>>> We don't need all these flags. >>>>>>>>>>>> If the user choose to compile DPDK for debug, every debug facilities >>>>>>>>>>>> should be enabled. Then at runtime it is possible to enable/disable >>>>>>>>>>>> the interesting logs. >>>>>>>>>>>> If you need to disable something which is not a log, >>>>>>>>>>>> you can align with the log level thanks to the function rte_log_can_log. >>>>>>>> For many libs these flags mean much more than just logging. >>>>>>>> Let say RTE_LIBRTE_ETHDEV_DEBUG changes behaviour of tx_prepare() for many >>>>>>>> drivers - extra validation performed. >>>>>>>> RTE_LIBRTE_MBUF_DEBUG makes __rte_mbuf_sanity_check() a call to real >>>>>>>> rte_mbuf_sanity_check() instead of just NOP. >>>>>>>> Which means performance would be greatly affected. >>>>>>>> RTE_LIBRTE_MEMPOOL_DEBUG changes format of the mempool object header >>>>>>>> and enforce extra checking, stats collection. >>>>>>>> etc. >>>>>>>> Probably that's ok for some cases to enable all that extra validation we have at once. >>>>>>>> But I suppose in many cases people just interested to enable debug on one >>>>>>>> (ok might be two/three) particular libraries, not the whole system. >>>>>>>> Right now there is such ability, we are going to remove it without >>>>>>>> providing adequate replacement. >>>>>>>> Approach with rte_log_can_log() seems workable, >>>>>>>> but right now these patches don't implement it. >>>>>>>> Konstantin >>>>>>>> >>>>>>>>>>>> Please let's stop complicating things for the contributors and the users. >>>>>>>>>>>> Note: I am strong on this position. >>>>>>>>>>>> >>>>>>>>>>> Note, this means that you need to ensure all debug printouts from libs and >>>>>>>>>>> drivers are using the RTE_LOG macros so can be runtime controlled. I think >>>>>>>>>>> that may be some distance from reality right now. >>>>>>>>>> Perfect! Let's expose those nasty logs which are not (yet) controllable. >>>>>>>>>> And next step is to block any patch in those drivers or libs, >>>>>>>>>> until it is fixed. Dynamic logging should have been complete for long. >>>>>>>>>> >>>>>>>>> I can live with that, I suppose. Do we have any idea of the magnitude of >>>>>>>>> the work required here? >>>>>>>>> >>>>>>>>>>> Even if we do want all debug enabled from one flag, I'm still not 100% >>>>>>>>>>> convinced that the existing debug flag is the way to do, since it only adds >>>>>>>>>>> debug info to binary without affecting code generation. >>>>>>>>>> OK, we want to keep this flag for gdb symbols only? >>>>>>>>>> And add a new flag for debugging facilities which hurt the runtime performance? >>>>>>>>>> >>>>>>>>> I think that would be wise, yes. We can call the option "rte_debug" or >>>>>>>>> something instead. >>>>>>>>> >>>>>>>>> /Bruce >>>>>>> OK, lets's summarize current opinions and requirements to make a >>>>>>> proposal for version2 of these patches, that I can implement if all agree: >>>>>>> >>>>>>> 1) The global debug flag is required to enable all the sanity checks and >>>>>>> validations that are normally not used due to performance reasons >>>>>> Yes >>>>>> >>>>>>> 2) The best option would be to have a single flag - not to introduce too >>>>>>> many build options >>>>>> Yes >>>>>> >>>>>>> 3) This option should be separated from meson "debug" option (used for >>>>>>> build with symbols) and can be called "rte_debug" >>>>>> Yes, it looks to be the consensus. >>>>>> >>>>>>> 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). >>>>>>> >>>>>>> 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. >>>>>> I don't understand difference between 4) et 5). >>>>> In current version of patches, I replaced all the DEBUG macros with >>>>> RTE_DEBUG. It would be much better to keep fine-grained debugs as they >>>>> are defined currently in dpdk. This is what I have on mind in 4) >>>>> >>>>> However the currently used debug macros have different naming >>>>> conventions: some use RTE_LIBRTE_{name}_DEBUG convention, other >>>>> RTE_{name}_DEBUG, some just {name}_DEBUG. >>>>> So in 5) I follow Bruce's proposal to standardize them to one form >>>>> RTE_DEBUG_{name}. However this will change the existing macros and >>>>> someone might not like it, so I ask for the opinion about it. >>>>> >>>> My thought is to standardize in the build and then leave it to module >>>> owners to either change their macros to use those standard ones as time >>>> goes on. >>> In order to maintain a good global user experience, >>> we need to drive such change with a roadmap and deadlines. >>> >>>>>>> Should they? Or should we leave the current debug macros? Please share >>>>>>> your opinions as I see both cons and pros of this idea. >>>>>> I am not sure we need to keep fine-grain debug flags per libs/drivers. >>>>>> In case RTE_DEBUG is enabled, which kind of debug processing >>>>>> (except logs) do we want to be able to disable? >>>>>> Is it possible to decide based on a call to rte_log_can_log()? >>>>> I think it's rather opposite way round. Sometimes we would like to >>>>> enable just some debug processing, e.g. when working on single lib or >>>>> driver. >>>>> If we will use rte_debug - every debug processing would be enabled, we >>>>> won't disable anything, but without rte_debug we will still have the >>>>> possibility of enabling debugs on a single module. >>>>> >>>>> I believe it is possible to do it with rte_log_can_log, but changing >>>>> build time enabled options into runtime enabled options might affect >>>>> performance. It might make working on a single library or driver harder. >>>>> >>>> I think the idea is to use both. When RTE_DEBUG is enabled, then the >>>> rte_log_can_log() calls will be used to control the actual output. Without >>>> RTE_DEBUG, the whole block is skipped. >>>> >>>> #ifdef RTE_DEBUG >>>> if rte_log_can_log(...) { >>>> /* do debug stuff */ >>>> } >>>> #endif >>> This is what I had in mind. >>> The question is about performance impact in the case >>> we enable RTE_DEBUG at compilation time, and don't enable a >>> specific debug at runtime: is this check overhead acceptable? >>> if rte_log_can_log(...) >> We probably wouldn't know the answer before trying. >> Probably best way to make such changes for rte_mbuf and see how >> big the drop will be. >> I suppose mbuf will be the one mostly affected, >> as we'll call rte_log_can_log() for nearly every mbuf op (free/detach/attach/reset, etc.) > Yes I like the idea of trying with mbuf, > and see how much a compilation flag for global debugging > affects the mbuf performance. I've just pushed v3 with minor fixes and mbuf performance tests. There are 6 very simple tests: * alloc_free allocates and frees mbufs from/to mempool one by one * bulk_alloc_free does the same but in bulks * data_manipulation uses few functions containing sanity checks (is_contiguous, append, trim, prepend, adj) * sanity_checks_without_header runs robust sanity checks (with header parameter = 0) * sanity_checks_with_header does full  sanity checks (with header parameter = 1) * sanity_checks_with_header_in_chain does the same as above, but all mbufs are chained into single list. I run those tests in 3 different compilations: * debug without_rte_log_can_log - sanity checks not empty, but without runtime checks of rte_log_can_log * debug with_rte_log_can_log - debug enabled and runtime checks used * no debug - debug mode  disabled - sanity checks are empty macros All the tests use 1024 mbufs of size (2048 + 128) and repeat test 1e6 times. I repeated every scenario 5 times and calculated average times as you can see in the below table. All times are in seconds. There is no much difference between both debug variants. Of course without rte_log it's slightly better, but the time deviation between samples is very big and in many cases bigger than differences. There is a huge difference between debug and non-debug scenarios especially in data_manipulation test case. So Konstantin, what do you think about these results. Can we apply similar patches for other libraries and drivers? > Note that we should also manage RTE_ENABLE_ASSERT with the global meson option. > > > > -- Lukasz Wojciechowski Principal Software Engineer Samsung R&D Institute Poland Samsung Electronics Office +48 22 377 88 25 l.wojciechow@partner.samsung.com