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

De Lara Guarch, Pablo pablo.de.lara.guarch at intel.com
Wed Apr 12 15:47:20 CEST 2017



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, April 12, 2017 2:29 PM
> To: De Lara Guarch, Pablo
> Cc: Olivier Matz; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/8] eal: dynamic logs
> 
> 2017-04-12 13:11, De Lara Guarch, Pablo:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > Sent: Wednesday, April 12, 2017 11:38 AM
> > > 2017-04-12 09:26, De Lara Guarch, Pablo:
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> > > > >
> > > > > The objective of this 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)
> > > > >
> > > > > Next step is to adapt drivers, libs and apps to use this new API. At
> the
> > > > > end, 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
> > > [...]
> > > > With this patch, all logs that use logtype "USERX" (e.g.
> > > RTE_LOGTYPE_USER1) are not shown anymore.
> > > > Should these macro be removed?
> > > >
> > > > Right now, all applications using this won't show these, so I assume
> that
> > > all of them
> > > > should be fixed before the release is out.
> > > > Is that correct?
> > >
> > > Is it a bug in the commit http://dpdk.org/commit/c1b5fa9 ?
> > > Note this line:
> > > 	__rte_log_register("user1", 24);
> >
> > This also happens with libraries, like HASH. I think the problem might be
> here:
> >
> > @@ -139,7 +266,11 @@ rte_vlog(uint32_t level, uint32_t logtype, const
> char *format, va_list ap)
> >  		}
> >  	}
> >
> > -	if ((level > rte_logs.level) || !(logtype & rte_logs.type))
> > +	if (level > rte_logs.level)
> > +		return 0;
> > +	if (logtype >= rte_logs.dynamic_types_len)
> > +		return -1;
> > +	if (level > rte_logs.dynamic_types[logtype].loglevel)
> >  		return 0;
> >
> > Type used to be a mask, so for instance, RTE_LOGTYPE_HASH 0x0...40 =
> 64 in decimal.
> > Therefore, logtype = 64 >= 34 = rte_logs.dynamic_types_len), so this
> won't be shown.
> > However, the PMDs or EAL will show it, because their logtype is less than
> 34.
> >
> > Am I missing something?
> 
> I think you are right.
> We are mixing old logtype and new ones.
> Should we redefine RTE_LOGTYPE_* values to the new values registered
> in rte_log_init?

I guess. I can send a patch for it and any concerns can be raised there?

Pablo


More information about the dev mailing list