[dpdk-dev] [RFC 0/8] eal: dynamic logs

Olivier Matz olivier.matz at 6wind.com
Fri Mar 17 16:32:33 CET 2017

Hi Thomas,

On Wed, 15 Mar 2017 17:35:32 +0100, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> 2017-02-06 14:29, Olivier Matz:
> > The objective of this RFC patchset is to introduce a framework to
> > support dynamic log types in EAL. It also provides one example of use
> > (in i40e).
> > 
> > Features:
> > - log types are identified by a string
> > - at registration, a uniq identifier is associated to a log type
> > - each log type can have its level changed dynamically
> > - extend command line parameters to set the log level of a specific
> >   type, or logs matching a regular expression
> > - keep compat with other legacy types (eal, malloc, ring, user*,
> >   etc... keep their hardcoded log type value)
> > 
> > At the end, when, we can expect that all non-dataplane logs are moved to
> > be dynamic, so we can enable/disable them at runtime, without
> > recompiling. Many debug options can probably be removed from
> > configuration:
> >   $ git grep DEBUG config/common_base | wc -l
> >   89  
> I think it would be a very nice cleanup and usability improvement.
> It seems that everybody agrees that dynamic logging config is better.
> There were 2 comments that I want to sum up here:
> 1/ Why not use an external log library?
> It is not obvious that there is a real benefit to use another system.
> And Olivier already wrote the code for this system.
> If someone writes the integration of another log system, we could
> consider it.
> 2/ Why filtering by log type instead of file/function?
> File/function filtering targets DPDK debug use cases.
> For application developers or system integrators, the log type seems
> a good level of abstraction for logging part of the system.
> Anyway, the file/function filtering could be added later if
> someone integrates it in the dynamic logging configuration system.
> The conclusion is that this series seems good to integrate.
> As it is a RFC, do you plan to send a refresh or can we merge it as is?

I'll send a refresh, the patchset does not apply on current master.


More information about the dev mailing list