> -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Wednesday, April 12, 2017 2:29 PM > To: De Lara Guarch, Pablo > Cc: Olivier Matz; dev@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.monja...@6wind.com] > > > Sent: Wednesday, April 12, 2017 11:38 AM > > > 2017-04-12 09:26, De Lara Guarch, Pablo: > > > > From: dev [mailto:dev-boun...@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
