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?