[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.
Regards,
Olivier
More information about the dev
mailing list