On Mon, Oct 3, 2016 at 6:27 PM, Wiles, Keith <keith.wiles at intel.com> wrote: >> On Oct 3, 2016, at 10:37 AM, Olivier Matz <olivier.matz at 6wind.com> wrote: >> What makes you feel it's easier to add a log level instead of adding a >> new RTE_LOG_DP() function? > > It seems to me the log levels are for displaying logs at different levels > adding a new macro to not log is just a hack because we do not have a log > level for data path. This is why I would like to see a log level added and > not a new macro. > > It also appears the new RTE_LOG() will always be in the code as you moved the > test to the RTE_LOG_DP() macro. This would mean all RTE_LOG() in the code > will always call rte_log(), correct? > > If using a new DEBUG_DP (maybe DATAPATH is a better log level name) level we > can use the same macro as before and modify the level only. This way we can > remove via the compiler any log that is below the default RTE_LOG_LEVEL. I > see keeping the rte_log() could be a performance problem or code blot when > you really want to remove them all. > > The DATAPATH log level would be above (smaller number) then DEBUG in the enum > list. To remove all debug logs just set the RTE_LOG_LEVEL to RTE_LOG_DATAPATH.
If I try to draw a parrallel to syslog (well, the log subsystem in eal has always been bound to syslog ...), what you propose here is like adding a new level in syslog while you have syslog facilities. With the current log api, we have types and levels, can't we filter at build time depending on the log "type" ? Here we would strip PMD type logs > INFO. -- David Marchand
