W dniu 11.07.2020 o 17:11, Thomas Monjalon pisze:
> 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?
Yes, I'll try.
This point was added after discussion about using a single RTE_DEBUG
flag for all debugs.
I think we all agreed that it will be better to keep separate flags for
separate libraries or drivers instead of using only one RTE_DEBUG flag
for all debugs.
e.g. in current version of patches there is a flag RTE_DEBUG_MBUF for
debugs related to librte_mbuf.
This allows to enable only some debugs at compile time passing them to
CFLAGS.
>> 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?
>
>
>
>
--
Lukasz Wojciechowski
Principal Software Engineer
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 88 25
l.wojciec...@partner.samsung.com
