All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] eal: fix log level/type retrieving on a standard pthread
@ 2016-05-09 16:13 Olivier Matz
  2016-05-11 16:39 ` Ferruh Yigit
  2016-05-17 15:56 ` David Marchand
  0 siblings, 2 replies; 5+ messages in thread
From: Olivier Matz @ 2016-05-09 16:13 UTC (permalink / raw)
  To: dev, david.marchand; +Cc: Maxime Leroy

From: Maxime Leroy <maxime.leroy@6wind.com>

The functions rte_log_cur_msg_loglevel() and rte_log_cur_msg_logtype()
return the current log level/type for the message being processed. They
are used when implementing a user-defined logging stream.

The current log levels and types were stored in a table indexed by the
lcore_id, only returning a valid value for dataplane threads. Setting
and getting these values in a non dataplane thread was ignored, using
the global value instead.

To fix this issue, a per-thread variable could be used (with
RTE_DEFINE_PER_LCORE), allowing any pthread to set and retrieve its
current log level or type.

Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
 lib/librte_eal/common/eal_common_log.c | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c
index 64aa79f..9526095 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -98,9 +98,10 @@ static int history_enabled = 1;
 struct log_cur_msg {
 	uint32_t loglevel; /**< log level - see rte_log.h */
 	uint32_t logtype;  /**< log type  - see rte_log.h */
-} __rte_cache_aligned;
-static struct log_cur_msg log_cur_msg[RTE_MAX_LCORE]; /**< per core log */
+};
 
+ /* per core log */
+static RTE_DEFINE_PER_LCORE(struct log_cur_msg, log_cur_msg);
 
 /* default logs */
 
@@ -205,21 +206,13 @@ rte_get_log_type(void)
 /* get the current loglevel for the message beeing processed */
 int rte_log_cur_msg_loglevel(void)
 {
-	unsigned lcore_id;
-	lcore_id = rte_lcore_id();
-	if (lcore_id >= RTE_MAX_LCORE)
-		return rte_get_log_level();
-	return log_cur_msg[lcore_id].loglevel;
+	return RTE_PER_LCORE(log_cur_msg).loglevel;
 }
 
 /* get the current logtype for the message beeing processed */
 int rte_log_cur_msg_logtype(void)
 {
-	unsigned lcore_id;
-	lcore_id = rte_lcore_id();
-	if (lcore_id >= RTE_MAX_LCORE)
-		return rte_get_log_type();
-	return log_cur_msg[lcore_id].logtype;
+	return RTE_PER_LCORE(log_cur_msg).logtype;
 }
 
 /* Dump log history to file */
@@ -273,17 +266,13 @@ rte_vlog(uint32_t level, uint32_t logtype, const char *format, va_list ap)
 {
 	int ret;
 	FILE *f = rte_logs.file;
-	unsigned lcore_id;
 
 	if ((level > rte_logs.level) || !(logtype & rte_logs.type))
 		return 0;
 
 	/* save loglevel and logtype in a global per-lcore variable */
-	lcore_id = rte_lcore_id();
-	if (lcore_id < RTE_MAX_LCORE) {
-		log_cur_msg[lcore_id].loglevel = level;
-		log_cur_msg[lcore_id].logtype = logtype;
-	}
+	RTE_PER_LCORE(log_cur_msg).loglevel = level;
+	RTE_PER_LCORE(log_cur_msg).logtype = logtype;
 
 	ret = vfprintf(f, format, ap);
 	fflush(f);
-- 
2.8.0.rc3

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

* Re: [PATCH] eal: fix log level/type retrieving on a standard pthread
  2016-05-09 16:13 [PATCH] eal: fix log level/type retrieving on a standard pthread Olivier Matz
@ 2016-05-11 16:39 ` Ferruh Yigit
  2016-05-12  9:22   ` Olivier MATZ
  2016-05-17 15:56 ` David Marchand
  1 sibling, 1 reply; 5+ messages in thread
From: Ferruh Yigit @ 2016-05-11 16:39 UTC (permalink / raw)
  To: Olivier Matz, dev, david.marchand; +Cc: Maxime Leroy

On 5/9/2016 5:13 PM, Olivier Matz wrote:
> From: Maxime Leroy <maxime.leroy@6wind.com>
> 
> The functions rte_log_cur_msg_loglevel() and rte_log_cur_msg_logtype()
> return the current log level/type for the message being processed. They
> are used when implementing a user-defined logging stream.
> 
> The current log levels and types were stored in a table indexed by the
> lcore_id, only returning a valid value for dataplane threads. Setting
> and getting these values in a non dataplane thread was ignored, using
> the global value instead.
> 
> To fix this issue, a per-thread variable could be used (with
> RTE_DEFINE_PER_LCORE), allowing any pthread to set and retrieve its
> current log level or type.
> 
> Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> ---
>  lib/librte_eal/common/eal_common_log.c | 25 +++++++------------------
>  1 file changed, 7 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c
> index 64aa79f..9526095 100644
> --- a/lib/librte_eal/common/eal_common_log.c
> +++ b/lib/librte_eal/common/eal_common_log.c
> @@ -98,9 +98,10 @@ static int history_enabled = 1;
>  struct log_cur_msg {
>  	uint32_t loglevel; /**< log level - see rte_log.h */
>  	uint32_t logtype;  /**< log type  - see rte_log.h */
> -} __rte_cache_aligned;

Removing alignment seems not related the main purpose of the patch. Is
this intentional?

<...>

I have tested with custom code, non-EAL thread have lcore_id value
UINT32_MAX, which is > RTE_MAX_LCORE and rte_log_cur_msg_loglevel gives
default log level as described in commit log. With this patch each
thread gets its own log level.

Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

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

* Re: [PATCH] eal: fix log level/type retrieving on a standard pthread
  2016-05-11 16:39 ` Ferruh Yigit
@ 2016-05-12  9:22   ` Olivier MATZ
  0 siblings, 0 replies; 5+ messages in thread
From: Olivier MATZ @ 2016-05-12  9:22 UTC (permalink / raw)
  To: Ferruh Yigit, dev, david.marchand; +Cc: Maxime Leroy

Hi Ferruh,

On 05/11/2016 06:39 PM, Ferruh Yigit wrote:
> On 5/9/2016 5:13 PM, Olivier Matz wrote:
>> --- a/lib/librte_eal/common/eal_common_log.c
>> +++ b/lib/librte_eal/common/eal_common_log.c
>> @@ -98,9 +98,10 @@ static int history_enabled = 1;
>>   struct log_cur_msg {
>>   	uint32_t loglevel; /**< log level - see rte_log.h */
>>   	uint32_t logtype;  /**< log type  - see rte_log.h */
>> -} __rte_cache_aligned;
>
> Removing alignment seems not related the main purpose of the patch. Is
> this intentional?

Initially, the structure was cache-aligned so each element of
the table was stored in a separate cache line, avoiding a lcore
accessing its element to polute its neighbors (this was by the
way a bit overkill as it's not a performance-sensitive structure).

Using a __thread variable instead of a table naturally removes this
need because it will be stored in a specific section containing only
per-core data.

> I have tested with custom code, non-EAL thread have lcore_id value
> UINT32_MAX, which is > RTE_MAX_LCORE and rte_log_cur_msg_loglevel gives
> default log level as described in commit log. With this patch each
> thread gets its own log level.
>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>

Thanks for reviewing and testing.

Regards,
Olivier

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

* Re: [PATCH] eal: fix log level/type retrieving on a standard pthread
  2016-05-09 16:13 [PATCH] eal: fix log level/type retrieving on a standard pthread Olivier Matz
  2016-05-11 16:39 ` Ferruh Yigit
@ 2016-05-17 15:56 ` David Marchand
  2016-05-18 14:50   ` Thomas Monjalon
  1 sibling, 1 reply; 5+ messages in thread
From: David Marchand @ 2016-05-17 15:56 UTC (permalink / raw)
  To: Olivier Matz; +Cc: dev, Maxime Leroy

On Mon, May 9, 2016 at 6:13 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
> From: Maxime Leroy <maxime.leroy@6wind.com>
>
> The functions rte_log_cur_msg_loglevel() and rte_log_cur_msg_logtype()
> return the current log level/type for the message being processed. They
> are used when implementing a user-defined logging stream.
>
> The current log levels and types were stored in a table indexed by the
> lcore_id, only returning a valid value for dataplane threads. Setting
> and getting these values in a non dataplane thread was ignored, using
> the global value instead.
>
> To fix this issue, a per-thread variable could be used (with
> RTE_DEFINE_PER_LCORE), allowing any pthread to set and retrieve its
> current log level or type.
>
> Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>

Acked-by: David Marchand <david.marchand@6wind.com>

-- 
David Marchand

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

* Re: [PATCH] eal: fix log level/type retrieving on a standard pthread
  2016-05-17 15:56 ` David Marchand
@ 2016-05-18 14:50   ` Thomas Monjalon
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Monjalon @ 2016-05-18 14:50 UTC (permalink / raw)
  To: Maxime Leroy; +Cc: dev, David Marchand, Olivier Matz

> > The functions rte_log_cur_msg_loglevel() and rte_log_cur_msg_logtype()
> > return the current log level/type for the message being processed. They
> > are used when implementing a user-defined logging stream.
> >
> > The current log levels and types were stored in a table indexed by the
> > lcore_id, only returning a valid value for dataplane threads. Setting
> > and getting these values in a non dataplane thread was ignored, using
> > the global value instead.
> >
> > To fix this issue, a per-thread variable could be used (with
> > RTE_DEFINE_PER_LCORE), allowing any pthread to set and retrieve its
> > current log level or type.
> >
> > Signed-off-by: Maxime Leroy <maxime.leroy@6wind.com>
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> 
> Acked-by: David Marchand <david.marchand@6wind.com>

Applied, thanks

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

end of thread, other threads:[~2016-05-18 14:50 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-09 16:13 [PATCH] eal: fix log level/type retrieving on a standard pthread Olivier Matz
2016-05-11 16:39 ` Ferruh Yigit
2016-05-12  9:22   ` Olivier MATZ
2016-05-17 15:56 ` David Marchand
2016-05-18 14:50   ` Thomas Monjalon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.