DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Arnaud Fiorini <arnaud.fiorini@polymtl.ca>,
	Thomas Monjalon <thomas@monjalon.net>,
	Jerin Jacob <jerinj@marvell.com>,
	Sunil Kumar Kori <skori@marvell.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Subject: Re: [PATCH 1/1] eal: add tracepoints to track lcores and services
Date: Wed, 3 May 2023 15:17:09 +0000	[thread overview]
Message-ID: <82db1dad-3d22-07ab-2431-8e3900e7df8d@ericsson.com> (raw)
In-Reply-To: <BL3PR11MB5699821D84A6ACBB8B9A13D4D76C9@BL3PR11MB5699.namprd11.prod.outlook.com>

On 2023-05-03 12:14, Van Haaren, Harry wrote:
>> -----Original Message-----
>> From: Arnaud Fiorini <arnaud.fiorini@polymtl.ca>
>> Sent: Monday, April 24, 2023 4:24 PM
>> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob <jerinj@marvell.com>;
>> Sunil Kumar Kori <skori@marvell.com>; Van Haaren, Harry
>> <harry.van.haaren@intel.com>
>> Cc: dev@dpdk.org; Arnaud Fiorini <arnaud.fiorini@polymtl.ca>
>> Subject: [PATCH 1/1] eal: add tracepoints to track lcores and services
>>
>> The tracepoints added are used to track lcore role and status,
>> as well as service mapping and service runstates. These
>> tracepoints are then used in analyses in Trace Compass.
>>
>> Signed-off-by: Arnaud Fiorini <arnaud.fiorini@polymtl.ca>
> 
> I've had a look at these changes, and don't have any big objections;
> When disabled, the tracepoints add no measurable overhead here, but
> When enabled they cause a ~+50% cycle-cost (eg from ~100 to 150 cycles).
> Running the "service_perf_autotest" prints cycle-costs, so this is easy to check.
> 
> Please add documentation on enabling the traces; today it is hard to identify/find
> an example of enabling tracing on service-cores. Suggest to add it to:
> 1) the commit message, how to enable service cores traces only
> 2) add a section in the service-cores documentation, to enable service-cores only, and link to tracing documentation page for more info.
> 
> +CC Mattias and Honnappa who have expressed specific interest in service-cores
> Performance in the past, any concerns/input Mattias/Honnappa?
> 

Adding tracepoints to DPDK services seems like a great idea to me.

> @Arnaud, assuming no concerns from wider DPDK community, I'm happy to Ack a v2 with docs added.
> 
> 
>> ---
>>   .mailmap                                 |  1 +
>>   lib/eal/common/eal_common_thread.c       |  4 ++
>>   lib/eal/common/eal_common_trace_points.c | 21 +++++++++
>>   lib/eal/common/rte_service.c             | 18 ++++++-
>>   lib/eal/include/eal_trace_internal.h     | 60 ++++++++++++++++++++++++
>>   5 files changed, 103 insertions(+), 1 deletion(-)
>>
>> diff --git a/.mailmap b/.mailmap
>> index dc30369117..2a0b132572 100644
>> --- a/.mailmap
>> +++ b/.mailmap
>> @@ -120,6 +120,7 @@ Archana Muniganti <marchana@marvell.com>
>> <muniganti.archana@caviumnetworks.com>
>>   Archit Pandey <architpandeynitk@gmail.com>
>>   Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
>>   Arkadiusz Kusztal <arkadiuszx.kusztal@intel.com>
>> +Arnaud Fiorini <arnaud.fiorini@polymtl.ca>
>>   Arnon Warshavsky <arnon@qwilt.com>
>>   Arshdeep Kaur <arshdeep.kaur@intel.com>
>>   Artem V. Andreev <artem.andreev@oktetlabs.ru>
>> diff --git a/lib/eal/common/eal_common_thread.c
>> b/lib/eal/common/eal_common_thread.c
>> index 079a385630..25dbdd68e3 100644
>> --- a/lib/eal/common/eal_common_thread.c
>> +++ b/lib/eal/common/eal_common_thread.c
>> @@ -205,6 +205,8 @@ eal_thread_loop(void *arg)
>>   				__ATOMIC_ACQUIRE)) == NULL)
>>   			rte_pause();
>>
>> +		rte_eal_trace_thread_lcore_running(lcore_id, f);
>> +
>>   		/* call the function and store the return value */
>>   		fct_arg = lcore_config[lcore_id].arg;
>>   		ret = f(fct_arg);
>> @@ -219,6 +221,8 @@ eal_thread_loop(void *arg)
>>   		 */
>>   		__atomic_store_n(&lcore_config[lcore_id].state, WAIT,
>>   			__ATOMIC_RELEASE);
>> +
>> +		rte_eal_trace_thread_lcore_stopped(lcore_id);
>>   	}
>>
>>   	/* never reached */
>> diff --git a/lib/eal/common/eal_common_trace_points.c
>> b/lib/eal/common/eal_common_trace_points.c
>> index 3f5bf5c55c..0f1240ea3a 100644
>> --- a/lib/eal/common/eal_common_trace_points.c
>> +++ b/lib/eal/common/eal_common_trace_points.c
>> @@ -70,6 +70,27 @@
>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_thread_remote_launch,
>>   	lib.eal.thread.remote.launch)
>>   RTE_TRACE_POINT_REGISTER(rte_eal_trace_thread_lcore_ready,
>>   	lib.eal.thread.lcore.ready)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_thread_lcore_running,
>> +	lib.eal.thread.lcore.running)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_thread_lcore_stopped,
>> +	lib.eal.thread.lcore.stopped)
>> +
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_map_lcore,
>> +	lib.eal.service.map.lcore)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_lcore_state_change,
>> +	lib.eal.service.lcore.state.change)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_lcore_start,
>> +	lib.eal.service.lcore.start)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_lcore_stop,
>> +	lib.eal.service.lcore.stop)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_run_begin,
>> +	lib.eal.service.run.begin)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_runstate_set,
>> +	lib.eal.service.run.state.set)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_run_end,
>> +	lib.eal.service.run.end)
>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_service_component_register,
>> +	lib.eal.service.component.register)
>>
>>   RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_register,
>>   	lib.eal.intr.register)
>> diff --git a/lib/eal/common/rte_service.c b/lib/eal/common/rte_service.c
>> index 42ca1d001d..5daec007aa 100644
>> --- a/lib/eal/common/rte_service.c
>> +++ b/lib/eal/common/rte_service.c
>> @@ -9,6 +9,7 @@
>>   #include <rte_service.h>
>>   #include <rte_service_component.h>
>>
>> +#include <eal_trace_internal.h>
>>   #include <rte_lcore.h>
>>   #include <rte_branch_prediction.h>
>>   #include <rte_common.h>
>> @@ -16,6 +17,7 @@
>>   #include <rte_atomic.h>
>>   #include <rte_malloc.h>
>>   #include <rte_spinlock.h>
>> +#include <rte_trace_point.h>
>>
>>   #include "eal_private.h"
>>
>> @@ -276,6 +278,8 @@ rte_service_component_register(const struct
>> rte_service_spec *spec,
>>   	if (id_ptr)
>>   		*id_ptr = free_slot;
>>
>> +	rte_eal_trace_service_component_register(free_slot, spec->name);
>> +
>>   	return 0;
>>   }
>>
>> @@ -336,6 +340,7 @@ rte_service_runstate_set(uint32_t id, uint32_t runstate)
>>   		__atomic_store_n(&s->app_runstate, RUNSTATE_STOPPED,
>>   			__ATOMIC_RELEASE);
>>
>> +	rte_eal_trace_service_runstate_set(id, runstate);
>>   	return 0;
>>   }
>>
>> @@ -427,11 +432,15 @@ service_run(uint32_t i, struct core_state *cs, uint64_t
>> service_mask,
>>   		if (!rte_spinlock_trylock(&s->execute_lock))
>>   			return -EBUSY;
>>
>> +		rte_eal_trace_service_run_begin(i, rte_lcore_id());

Should you move the trace point to the runner function, to avoid 
duplication?

>>   		service_runner_do_callback(s, cs, i);
>>   		rte_spinlock_unlock(&s->execute_lock);
>> -	} else
>> +	} else {
>> +		rte_eal_trace_service_run_begin(i, rte_lcore_id());
>>   		service_runner_do_callback(s, cs, i);
>> +	}
>>
>> +	rte_eal_trace_service_run_end(i, rte_lcore_id());
>>   	return 0;
>>   }
>>
>> @@ -658,6 +667,7 @@ int32_t
>>   rte_service_map_lcore_set(uint32_t id, uint32_t lcore, uint32_t enabled)
>>   {
>>   	uint32_t on = enabled > 0;
>> +	rte_eal_trace_service_map_lcore(id, lcore, enabled);
>>   	return service_update(id, lcore, &on, 0);
>>   }
>>
>> @@ -683,6 +693,8 @@ set_lcore_state(uint32_t lcore, int32_t state)
>>
>>   	/* update per-lcore optimized state tracking */
>>   	lcore_states[lcore].is_service_core = (state == ROLE_SERVICE);
>> +
>> +	rte_eal_trace_service_lcore_state_change(lcore, state);
>>   }
>>
>>   int32_t
>> @@ -780,6 +792,8 @@ rte_service_lcore_start(uint32_t lcore)
>>   	 */
>>   	__atomic_store_n(&cs->runstate, RUNSTATE_RUNNING,
>> __ATOMIC_RELEASE);
>>
>> +	rte_eal_trace_service_lcore_start(lcore);
>> +
>>   	int ret = rte_eal_remote_launch(service_runner_func, 0, lcore);
>>   	/* returns -EBUSY if the core is already launched, 0 on success */
>>   	return ret;
>> @@ -824,6 +838,8 @@ rte_service_lcore_stop(uint32_t lcore)
>>   	__atomic_store_n(&lcore_states[lcore].runstate, RUNSTATE_STOPPED,
>>   		__ATOMIC_RELEASE);
>>
>> +	rte_eal_trace_service_lcore_stop(lcore);
>> +
>>   	return 0;
>>   }
>>
>> diff --git a/lib/eal/include/eal_trace_internal.h
>> b/lib/eal/include/eal_trace_internal.h
>> index 57d6de2535..9a37a08567 100644
>> --- a/lib/eal/include/eal_trace_internal.h
>> +++ b/lib/eal/include/eal_trace_internal.h
>> @@ -174,6 +174,66 @@ RTE_TRACE_POINT(
>>   	rte_trace_point_emit_u32(lcore_id);
>>   	rte_trace_point_emit_string(cpuset);
>>   )
>> +RTE_TRACE_POINT_FP(
>> +	rte_eal_trace_thread_lcore_running,
>> +	RTE_TRACE_POINT_ARGS(unsigned int lcore_id, void *f),
>> +	rte_trace_point_emit_u32(lcore_id);

There's a certain asymmetry here, with lcore_id being called both a 
uint32_t and unsigned int.

I see now there is no rte_tracepoint_emit_uint(), so maybe this is the 
best you can do.

Those two types are the same on anything DPDK supports anyway, I think, 
so it's a cosmetic issue only.

>> +	rte_trace_point_emit_ptr(f);
>> +)
>> +RTE_TRACE_POINT_FP(
>> +	rte_eal_trace_thread_lcore_stopped,
>> +	RTE_TRACE_POINT_ARGS(unsigned int lcore_id),
>> +	rte_trace_point_emit_u32(lcore_id);
>> +)
>> +
>> +/* Service */
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_map_lcore,
>> +	RTE_TRACE_POINT_ARGS(unsigned int id, unsigned int lcore_id, unsigned int
>> enabled),
>> +	rte_trace_point_emit_u32(id);
>> +	rte_trace_point_emit_u32(lcore_id);
>> +	rte_trace_point_emit_u32(enabled);
>> +)
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_lcore_state_change,
>> +	RTE_TRACE_POINT_ARGS(unsigned int lcore_id, int lcore_state),
>> +	rte_trace_point_emit_u32(lcore_id);
>> +	rte_trace_point_emit_i32(lcore_state);
>> +)
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_lcore_start,
>> +	RTE_TRACE_POINT_ARGS(unsigned int lcore_id),
>> +	rte_trace_point_emit_u32(lcore_id);
>> +)
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_lcore_stop,
>> +	RTE_TRACE_POINT_ARGS(unsigned int lcore_id),
>> +	rte_trace_point_emit_u32(lcore_id);
>> +)
>> +RTE_TRACE_POINT_FP(
>> +	rte_eal_trace_service_run_begin,
>> +	RTE_TRACE_POINT_ARGS(unsigned int id, unsigned int lcore_id),
>> +	rte_trace_point_emit_u32(id);
>> +	rte_trace_point_emit_u32(lcore_id);
>> +)
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_runstate_set,
>> +	RTE_TRACE_POINT_ARGS(unsigned int id, unsigned int run_state),
>> +	rte_trace_point_emit_u32(id);
>> +	rte_trace_point_emit_u32(run_state);
>> +)
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_run_end,
>> +	RTE_TRACE_POINT_ARGS(unsigned int id, unsigned int lcore_id),
>> +	rte_trace_point_emit_u32(id);
>> +	rte_trace_point_emit_u32(lcore_id);
>> +)
>> +RTE_TRACE_POINT(
>> +	rte_eal_trace_service_component_register,
>> +	RTE_TRACE_POINT_ARGS(int id, const char *service_name),
>> +	rte_trace_point_emit_i32(id);
>> +	rte_trace_point_emit_string(service_name);
>> +)
>>
>>   #ifdef __cplusplus
>>   }
>> --
>> 2.25.1


      reply	other threads:[~2023-05-03 15:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24 15:24 [PATCH 0/1] " Arnaud Fiorini
2023-04-24 15:24 ` [PATCH 1/1] " Arnaud Fiorini
2023-05-03 10:14   ` Van Haaren, Harry
2023-05-03 15:17     ` Mattias Rönnblom [this message]

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=82db1dad-3d22-07ab-2431-8e3900e7df8d@ericsson.com \
    --to=mattias.ronnblom@ericsson.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=arnaud.fiorini@polymtl.ca \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=jerinj@marvell.com \
    --cc=skori@marvell.com \
    --cc=thomas@monjalon.net \
    /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).