DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] rte_log simplification using constructor scheme
@ 2020-05-27 16:05 Jerin Kollanukkaran
  2020-06-08 20:25 ` Thomas Monjalon
  0 siblings, 1 reply; 3+ messages in thread
From: Jerin Kollanukkaran @ 2020-05-27 16:05 UTC (permalink / raw)
  To: Olivier Matz, david.marchand, dpdk-dev

Based on the discussion happed on http://patches.dpdk.org/patch/69681/,
I would like simply the rte_log to use constructor scheme and submit patch to
update existing consumer of rte_log to use new scheme for v20.08.
RTE_LOG_REGISTER will an optional symbol to use the rte_log registration mechanism.

Let me know if there any overlap on someone's else work on the same area or any objections?

Example cleanup for  octeontx2 driver.

diff --git a/drivers/common/octeontx2/otx2_common.c
b/drivers/common/octeontx2/otx2_common.c
index 1a257cf07..4d391a7e0 100644
--- a/drivers/common/octeontx2/otx2_common.c
+++ b/drivers/common/octeontx2/otx2_common.c
@@ -169,89 +169,13 @@ int otx2_npa_lf_obj_ref(void)
        return cnt ? 0 : -EINVAL;
 }
-/**
- * @internal
- */
-int otx2_logtype_base;
-/**
- * @internal
- */
-int otx2_logtype_mbox;
-/**
- * @internal
- */
-int otx2_logtype_npa;
-/**
- * @internal
- */
-int otx2_logtype_nix;
-/**
- * @internal
- */
-int otx2_logtype_npc;
-/**
- * @internal
- */
-int otx2_logtype_tm;
-/**
- * @internal
- */
-int otx2_logtype_sso;
-/**
- * @internal
- */
-int otx2_logtype_tim;
-/**
- * @internal
- */
-int otx2_logtype_dpi;
-/**
- * @internal
- */
-int otx2_logtype_ep;
-
-RTE_INIT(otx2_log_init);
-static void
-otx2_log_init(void)
-{
-       otx2_logtype_base = rte_log_register("pmd.octeontx2.base");
-       if (otx2_logtype_base >= 0)
-               rte_log_set_level(otx2_logtype_base, RTE_LOG_NOTICE);
-
-       otx2_logtype_mbox = rte_log_register("pmd.octeontx2.mbox");
-       if (otx2_logtype_mbox >= 0)
-               rte_log_set_level(otx2_logtype_mbox, RTE_LOG_NOTICE);
-
-       otx2_logtype_npa = rte_log_register("pmd.mempool.octeontx2");
-       if (otx2_logtype_npa >= 0)
-               rte_log_set_level(otx2_logtype_npa, RTE_LOG_NOTICE);
-
-       otx2_logtype_nix = rte_log_register("pmd.net.octeontx2");
-       if (otx2_logtype_nix >= 0)
-               rte_log_set_level(otx2_logtype_nix, RTE_LOG_NOTICE);
-
-       otx2_logtype_npc = rte_log_register("pmd.net.octeontx2.flow");
-       if (otx2_logtype_npc >= 0)
-               rte_log_set_level(otx2_logtype_npc, RTE_LOG_NOTICE);
-
-       otx2_logtype_tm = rte_log_register("pmd.net.octeontx2.tm");
-       if (otx2_logtype_tm >= 0)
-               rte_log_set_level(otx2_logtype_tm, RTE_LOG_NOTICE);
-
-       otx2_logtype_sso = rte_log_register("pmd.event.octeontx2");
-       if (otx2_logtype_sso >= 0)
-               rte_log_set_level(otx2_logtype_sso, RTE_LOG_NOTICE);
-
-       otx2_logtype_tim = rte_log_register("pmd.event.octeontx2.timer");
-       if (otx2_logtype_tim >= 0)
-               rte_log_set_level(otx2_logtype_tim, RTE_LOG_NOTICE);
-
-       otx2_logtype_dpi = rte_log_register("pmd.raw.octeontx2.dpi");
-       if (otx2_logtype_dpi >= 0)
-               rte_log_set_level(otx2_logtype_dpi, RTE_LOG_NOTICE);
-
-       otx2_logtype_ep = rte_log_register("pmd.raw.octeontx2.ep");
-       if (otx2_logtype_ep >= 0)
-               rte_log_set_level(otx2_logtype_ep, RTE_LOG_NOTICE);
-
-}
+RTE_LOG_REGISTER(otx2_logtype_base, pmd.octeontx2.base, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_mbox, pmd.octeontx2.mbox, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_npa, pmd.mempool.octeontx2, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_nix, pmd.net.octeontx2, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_npc, pmd.net.octeontx2.flow, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_tm, pmd.net.octeontx2.tm, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_sso, pmd.event.octeontx2, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_tim, pmd.event.octeontx2.timer, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_dpi, pmd.raw.octeontx2.dpi, NOTICE);
+RTE_LOG_REGISTER(otx2_logtype_ep, pmd.raw.octeontx2.ep, NOTICE);

diff --git a/lib/librte_eal/include/rte_log.h b/lib/librte_eal/include/rte_log.h
index 1789ede56..22fc3802f 100644
--- a/lib/librte_eal/include/rte_log.h
+++ b/lib/librte_eal/include/rte_log.h
@@ -376,6 +376,15 @@ int rte_vlog(uint32_t level, uint32_t logtype,
const char *format, va_list ap)
                 RTE_LOGTYPE_ ## t, # t ": " __VA_ARGS__) :     \
         0)

+#define RTE_LOG_REGISTER(type, name, level)                            \
+int type;                                                              \
+RTE_INIT(__##type)                                                     \
+{                                                                      \
+       type = rte_log_register(RTE_STR(name));                         \
+       if (type >= 0)                                                  \
+               rte_log_set_level(type, RTE_LOG_##level);               \
+}
+
 #ifdef __cplusplus
 }
 #endif

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] rte_log simplification using constructor scheme
  2020-05-27 16:05 [dpdk-dev] rte_log simplification using constructor scheme Jerin Kollanukkaran
@ 2020-06-08 20:25 ` Thomas Monjalon
  2020-06-17  6:40   ` Jerin Jacob
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas Monjalon @ 2020-06-08 20:25 UTC (permalink / raw)
  To: Jerin Kollanukkaran; +Cc: Olivier Matz, david.marchand, dpdk-dev, arybchenko

27/05/2020 18:05, Jerin Kollanukkaran:
> +#define RTE_LOG_REGISTER(type, name, level)                            \
> +int type;                                                              \
> +RTE_INIT(__##type)                                                     \
> +{                                                                      \
> +       type = rte_log_register(RTE_STR(name));                         \
> +       if (type >= 0)                                                  \
> +               rte_log_set_level(type, RTE_LOG_##level);               \
> +}

We should consider using rte_log_register_type_and_pick_level()
which works for drivers loaded later in the init sequence.
I feel rte_log_register() could be deprecated.

The other question around log level is about the default level.
Do we want to allow having different default log levels per log type?



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] rte_log simplification using constructor scheme
  2020-06-08 20:25 ` Thomas Monjalon
@ 2020-06-17  6:40   ` Jerin Jacob
  0 siblings, 0 replies; 3+ messages in thread
From: Jerin Jacob @ 2020-06-17  6:40 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Jerin Kollanukkaran, Olivier Matz, david.marchand, dpdk-dev,
	Andrew Rybchenko

On Tue, Jun 9, 2020 at 1:55 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 27/05/2020 18:05, Jerin Kollanukkaran:
> > +#define RTE_LOG_REGISTER(type, name, level)                            \
> > +int type;                                                              \
> > +RTE_INIT(__##type)                                                     \
> > +{                                                                      \
> > +       type = rte_log_register(RTE_STR(name));                         \
> > +       if (type >= 0)                                                  \
> > +               rte_log_set_level(type, RTE_LOG_##level);               \
> > +}
>
> We should consider using rte_log_register_type_and_pick_level()
> which works for drivers loaded later in the init sequence.

I sent the first version[1] based on the current driver usage to avoid
any behavior change. (Major work is changing the drivers, we can
decide the RTE_LOG_REGISTER definition in next versions)
[1]
http://patches.dpdk.org/patch/71650/
I will send the v2 based on the consensus.
Please comment on http://patches.dpdk.org/patch/71650/.

> I feel rte_log_register() could be deprecated.

No strong opinion on this. @Olivier Matz , Thoughts?

> The other question around log level is about the default level.
> Do we want to allow having different default log levels per log type?

Currently, drivers are using various levels per log type. I can send
the v2 based on
the consensus.


>
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-06-17  6:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-27 16:05 [dpdk-dev] rte_log simplification using constructor scheme Jerin Kollanukkaran
2020-06-08 20:25 ` Thomas Monjalon
2020-06-17  6:40   ` Jerin Jacob

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).