Re: [dpdk-dev] [PATCH] log: do not drop debug logs at compile time

[Olivier Matz <olivier.matz@6wind.com>]

Hi David,

On 10/04/2016 10:28 AM, David Marchand wrote:
> On Mon, Oct 3, 2016 at 6:27 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
>>> On Oct 3, 2016, at 10:37 AM, Olivier Matz <olivier.matz@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.

I think we may have dataplane logs in other part of the code: in the
application (log type = USER), and surely in some dpdk libraries.

Moreover, as the behavior of the macro changes (in one case it is
stripped at compilation, in the other case not), I'd say having
different functions is clearer for the developer than having a different
behavior depending on log level or log type.

Regards,
Olivier