From: David Marchand <david.marchand@redhat.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 02/11] log: define logtype register wrapper for drivers
Date: Tue, 3 Sep 2019 10:06:24 +0200 [thread overview]
Message-ID: <CAJFAV8w3Wio_MjwL_F5iZThWi3HpTpwRwqrmpYoxYk0D6-D0Rg@mail.gmail.com> (raw)
In-Reply-To: <064b2195-434d-d76f-a59c-8fad6d235f58@intel.com>
On Mon, Sep 2, 2019 at 4:29 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>
> On 8/19/2019 12:41 PM, David Marchand wrote:
> > The function rte_log_register_type_and_pick_level() fills a gap for
> > dynamically loaded code (especially drivers) who would not pick up
> > the log level passed at startup.
> >
> > Let's promote it to stable and export it for use by drivers via
> > a wrapper.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > ---
> > lib/librte_eal/common/include/rte_log.h | 12 ++++++++----
> > lib/librte_eal/rte_eal_version.map | 8 +++++++-
> > 2 files changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
> > index cbb4184..c3aff00 100644
> > --- a/lib/librte_eal/common/include/rte_log.h
> > +++ b/lib/librte_eal/common/include/rte_log.h
> > @@ -209,9 +209,6 @@ int rte_log_cur_msg_logtype(void);
> > int rte_log_register(const char *name);
> >
> > /**
> > - * @warning
> > - * @b EXPERIMENTAL: this API may change without prior notice
> > - *
> > * Register a dynamic log type and try to pick its level from EAL options
> > *
> > * rte_log_register() is called inside. If successful, the function tries
> > @@ -227,9 +224,16 @@ int rte_log_register(const char *name);
> > * - >=0: the newly registered log type
> > * - <0: rte_log_register() error value
> > */
> > -__rte_experimental
> > int rte_log_register_type_and_pick_level(const char *name, uint32_t level_def);
>
> +1 to remove experimental from the API.
>
> >
> > +#define RTE_LOG_REGISTER(token, name, level, fallback) \
> > +RTE_INIT(token##_init) \
>
> Does it still need to be an init time call?
> Since it is dynamic now it can be during probe, even log name can be a paramter
> to the "struct rte_driver" and log can be registered automatically during probe,
> not sure how complex it becomes.
This would not work with non driver components built as shared
libraries (unless they have an explicit init symbol in the dpdk init
flow).
The drivers can register multiple log types so this would have to be handled.
We would touch the struct rte_driver which is embedded in other
objects like rte_pci_driver, breaking the abi.
>
> > +{ \
> > + token = rte_log_register_type_and_pick_level(name, level); \
> > + if (token < 0) \
>
> The failure can be because component can try to register existing log name, or
> there is no enough memory, do you think does it worth to do log, or some
> additional work if component is trying to register existing log name?
Yes, I can raise a warning log (using RTE_LOGTYPE_EAL type), since
duplicates are not supposed to happen.
>
> > + token = fallback; \
>
> Does the 'fallback' needs to be provided by user, it looks like everyone will
> just copy/paste 'RTE_LOGTYPE_PMD' for drivers, and does it really needs to be
> configurable since it is fallback.
This series only touches drivers, but I expected other components
would use this macro later.
I can add a RTE_PMD_REGISTER_LOG macro that hides the RTE_LOGTYPE_PMD
fallback value.
>
> Why not provide a hardcoded type for the failure case? And for that case perhaps
> create a more generic logtype, something like "RTE_LOGTYPE_FALLBACK" so that it
> can be as it is from all components?
>
I prefer to map all drivers to a logtype that means something, like
RTE_LOGTYPE_PMD.
Having a "fallback" could be used for all components, but this would
have to be a static logtype and adding one is not possible without
breaking the abi (static entries are < 32 and all values are used).
--
David Marchand
next prev parent reply other threads:[~2019-09-03 8:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 11:41 [dpdk-dev] [PATCH 00/11] Fixing log levels for dynamically loaded drivers David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 01/11] log: fix plugin level restore with patterns David Marchand
2019-08-19 12:30 ` Andrew Rybchenko
2019-08-19 11:41 ` [dpdk-dev] [PATCH 02/11] log: define logtype register wrapper for drivers David Marchand
2019-08-19 12:27 ` Andrew Rybchenko
2019-09-02 14:29 ` Ferruh Yigit
2019-09-03 8:06 ` David Marchand [this message]
2019-09-03 8:47 ` Ferruh Yigit
2019-09-04 17:45 ` Thomas Monjalon
2019-09-04 19:21 ` Andrew Rybchenko
2019-09-04 19:41 ` Thomas Monjalon
2019-09-04 19:58 ` Andrew Rybchenko
2019-09-04 20:44 ` Thomas Monjalon
2019-09-05 6:29 ` Andrew Rybchenko
2019-09-05 7:13 ` David Marchand
2019-09-05 7:45 ` Thomas Monjalon
2019-08-19 11:41 ` [dpdk-dev] [PATCH 03/11] drivers/baseband: use new logtype wrapper David Marchand
2019-08-19 15:39 ` Chautru, Nicolas
2019-08-19 11:41 ` [dpdk-dev] [PATCH 04/11] drivers/bus: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 05/11] drivers/common: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 06/11] drivers/compress: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 07/11] drivers/crypto: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 08/11] drivers/event: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 09/11] drivers/mempool: " David Marchand
2019-08-19 11:41 ` [dpdk-dev] [PATCH 10/11] drivers/net: " David Marchand
2019-08-19 14:55 ` Legacy, Allain
2019-09-02 16:11 ` Ferruh Yigit
2019-09-03 8:06 ` David Marchand
2019-09-03 15:03 ` Stephen Hemminger
2019-08-19 11:41 ` [dpdk-dev] [PATCH 11/11] drivers/raw: " David Marchand
2019-09-02 14:17 ` [dpdk-dev] [PATCH 00/11] Fixing log levels for dynamically loaded drivers Ferruh Yigit
2019-09-03 8:06 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJFAV8w3Wio_MjwL_F5iZThWi3HpTpwRwqrmpYoxYk0D6-D0Rg@mail.gmail.com \
--to=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).