* [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2
@ 2020-05-03 20:31 David Marchand
2020-05-03 20:31 ` [dpdk-dev] [PATCH 1/8] cryptodev: fix trace points registration David Marchand
` (8 more replies)
0 siblings, 9 replies; 55+ messages in thread
From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw)
To: dev; +Cc: thomas
Couple of fixes and cleanup (missed during initial review) on the newly
introduced traces framework.
Phil patch [1] has been rebased as part of this series.
1: http://patchwork.dpdk.org/patch/69467/
--
David Marchand
David Marchand (7):
cryptodev: fix trace points registration
trace: simplify trace point registration
trace: simplify trace point headers
trace: avoid confusion on optarg
trace: remove unneeded checks in internal API
trace: remove limitation on patterns number
trace: remove string duplication
Phil Yang (1):
trace: fix build with gcc 10
app/test/test_trace_register.c | 15 +-
doc/guides/prog_guide/trace_lib.rst | 31 +--
lib/librte_cryptodev/cryptodev_trace_points.c | 82 +++----
lib/librte_eal/common/eal_common_trace.c | 10 +-
.../common/eal_common_trace_points.c | 166 ++++++--------
.../common/eal_common_trace_utils.c | 85 +++----
lib/librte_eal/common/eal_trace.h | 16 +-
lib/librte_eal/include/meson.build | 1 -
lib/librte_eal/include/rte_eal_trace.h | 122 +++++------
lib/librte_eal/include/rte_trace_point.h | 154 ++++++++++---
.../include/rte_trace_point_provider.h | 131 -----------
.../include/rte_trace_point_register.h | 15 +-
lib/librte_ethdev/ethdev_trace_points.c | 46 ++--
lib/librte_eventdev/eventdev_trace_points.c | 207 +++++++-----------
lib/librte_mempool/mempool_trace_points.c | 126 +++++------
15 files changed, 492 insertions(+), 715 deletions(-)
delete mode 100644 lib/librte_eal/include/rte_trace_point_provider.h
--
2.23.0
^ permalink raw reply [flat|nested] 55+ messages in thread* [dpdk-dev] [PATCH 1/8] cryptodev: fix trace points registration 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 7:41 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration David Marchand ` (7 subsequent siblings) 8 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev; +Cc: thomas, Declan Doherty, Sunil Kumar Kori Those trace points are defined but not registered. Fixes: 4cf30e3f3c35 ("cryptodev: add tracepoints") Signed-off-by: David Marchand <david.marchand@redhat.com> --- lib/librte_cryptodev/cryptodev_trace_points.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lib/librte_cryptodev/cryptodev_trace_points.c b/lib/librte_cryptodev/cryptodev_trace_points.c index 9df213e25b..7d03c93882 100644 --- a/lib/librte_cryptodev/cryptodev_trace_points.c +++ b/lib/librte_cryptodev/cryptodev_trace_points.c @@ -61,6 +61,12 @@ RTE_INIT(cryptodev_trace_init) RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_init, lib.cryptodev.asym.init); + RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_clear, + lib.cryptodev.sym.clear); + + RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_clear, + lib.cryptodev.asym.clear); + RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_enqueue_burst, lib.cryptodev.enq.burst); -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 1/8] cryptodev: fix trace points registration 2020-05-03 20:31 ` [dpdk-dev] [PATCH 1/8] cryptodev: fix trace points registration David Marchand @ 2020-05-04 7:41 ` Sunil Kumar Kori 0 siblings, 0 replies; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-04 7:41 UTC (permalink / raw) To: David Marchand, dev; +Cc: thomas, Declan Doherty >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 2:01 AM >To: dev@dpdk.org >Cc: thomas@monjalon.net; Declan Doherty <declan.doherty@intel.com>; >Sunil Kumar Kori <skori@marvell.com> >Subject: [EXT] [PATCH 1/8] cryptodev: fix trace points registration > >External Email > >---------------------------------------------------------------------- >Those trace points are defined but not registered. > >Fixes: 4cf30e3f3c35 ("cryptodev: add tracepoints") > >Signed-off-by: David Marchand <david.marchand@redhat.com> >--- > lib/librte_cryptodev/cryptodev_trace_points.c | 6 ++++++ > 1 file changed, 6 insertions(+) > >diff --git a/lib/librte_cryptodev/cryptodev_trace_points.c >b/lib/librte_cryptodev/cryptodev_trace_points.c >index 9df213e25b..7d03c93882 100644 >--- a/lib/librte_cryptodev/cryptodev_trace_points.c >+++ b/lib/librte_cryptodev/cryptodev_trace_points.c >@@ -61,6 +61,12 @@ RTE_INIT(cryptodev_trace_init) > > RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_init >, > lib.cryptodev.asym.init); > >+ > RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_clear >, >+ lib.cryptodev.sym.clear); >+ >+ > RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_cle >ar, >+ lib.cryptodev.asym.clear); >+ > RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_enqueue_burst, > lib.cryptodev.enq.burst); > >-- Acked-by: Sunil Kumar Kori <skori@marvell.com> >2.23.0 ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand 2020-05-03 20:31 ` [dpdk-dev] [PATCH 1/8] cryptodev: fix trace points registration David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 2:46 ` Jerin Jacob ` (2 more replies) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 3/8] trace: simplify trace point headers David Marchand ` (6 subsequent siblings) 8 siblings, 3 replies; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev Cc: thomas, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. Signed-off-by: David Marchand <david.marchand@redhat.com> --- app/test/test_trace_register.c | 12 +- doc/guides/prog_guide/trace_lib.rst | 12 +- lib/librte_cryptodev/cryptodev_trace_points.c | 84 +++---- .../common/eal_common_trace_points.c | 164 ++++++-------- lib/librte_eal/include/rte_eal_trace.h | 122 +++++------ lib/librte_eal/include/rte_trace_point.h | 14 +- .../include/rte_trace_point_register.h | 6 +- lib/librte_ethdev/ethdev_trace_points.c | 44 ++-- lib/librte_eventdev/eventdev_trace_points.c | 205 +++++++----------- lib/librte_mempool/mempool_trace_points.c | 124 ++++------- 10 files changed, 309 insertions(+), 478 deletions(-) diff --git a/app/test/test_trace_register.c b/app/test/test_trace_register.c index 8f40822cad..7feacfbabc 100644 --- a/app/test/test_trace_register.c +++ b/app/test/test_trace_register.c @@ -5,13 +5,5 @@ #include "test_trace.h" -/* Define trace points */ -RTE_TRACE_POINT_DEFINE(app_dpdk_test_tp); -RTE_TRACE_POINT_DEFINE(app_dpdk_test_fp); - -RTE_INIT(register_valid_trace_points) -{ - RTE_TRACE_POINT_REGISTER(app_dpdk_test_tp, app.dpdk.test.tp); - RTE_TRACE_POINT_REGISTER(app_dpdk_test_fp, app.dpdk.test.fp); -} - +RTE_TRACE_POINT_REGISTER(app_dpdk_test_tp, app.dpdk.test.tp) +RTE_TRACE_POINT_REGISTER(app_dpdk_test_fp, app.dpdk.test.fp) diff --git a/doc/guides/prog_guide/trace_lib.rst b/doc/guides/prog_guide/trace_lib.rst index 6a2016c7dc..9cad4ff4ac 100644 --- a/doc/guides/prog_guide/trace_lib.rst +++ b/doc/guides/prog_guide/trace_lib.rst @@ -101,12 +101,7 @@ Register the tracepoint #include <my_tracepoint_provider.h> - RTE_TRACE_POINT_DEFINE(app_trace_string); - - RTE_INIT(app_trace_init) - { - RTE_TRACE_POINT_REGISTER(app_trace_string, app.trace.string); - } + RTE_TRACE_POINT_REGISTER(app_trace_string, app.trace.string) The above code snippet registers the ``app_trace_string`` tracepoint to trace library. Here, the ``my_tracepoint_provider.h`` is the header file @@ -119,9 +114,6 @@ There is no requirement for the tracepoint function and its name to be similar. However, it is recommended to have a similar name for a better naming convention. -The user must register the tracepoint before the ``rte_eal_init`` invocation. -The user can use the ``RTE_INIT`` construction scheme to achieve this. - .. note:: The ``RTE_TRACE_POINT_REGISTER_SELECT`` must be defined before including the @@ -129,7 +121,7 @@ The user can use the ``RTE_INIT`` construction scheme to achieve this. .. note:: - The ``RTE_TRACE_POINT_DEFINE`` defines the placeholder for the + The ``RTE_TRACE_POINT_REGISTER`` defines the placeholder for the ``rte_trace_point_t`` tracepoint object. The user must export a ``__<trace_function_name>`` symbol in the library ``.map`` file for this tracepoint to be used out of the library, in shared builds. diff --git a/lib/librte_cryptodev/cryptodev_trace_points.c b/lib/librte_cryptodev/cryptodev_trace_points.c index 7d03c93882..aa31103404 100644 --- a/lib/librte_cryptodev/cryptodev_trace_points.c +++ b/lib/librte_cryptodev/cryptodev_trace_points.c @@ -6,70 +6,50 @@ #include "rte_cryptodev_trace.h" -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_configure); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_start); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_stop); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_close); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_queue_pair_setup); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_pool_create); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_create); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_create); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_free); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_free); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_init); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_init); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_clear); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_clear); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_enqueue_burst); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_dequeue_burst); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_configure, + lib.cryptodev.configure) -RTE_INIT(cryptodev_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_configure, - lib.cryptodev.configure); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_start, + lib.cryptodev.start) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_start, - lib.cryptodev.start); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_stop, + lib.cryptodev.stop) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_stop, - lib.cryptodev.stop); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_close, + lib.cryptodev.close) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_close, - lib.cryptodev.close); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_queue_pair_setup, + lib.cryptodev.queue.pair.setup) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_queue_pair_setup, - lib.cryptodev.queue.pair.setup); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_pool_create, + lib.cryptodev.sym.pool.create) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_pool_create, - lib.cryptodev.sym.pool.create); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_create, + lib.cryptodev.sym.create) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_create, - lib.cryptodev.sym.create); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_create, + lib.cryptodev.asym.create) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_create, - lib.cryptodev.asym.create); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_free, + lib.cryptodev.sym.free) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_free, - lib.cryptodev.sym.free); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_free, + lib.cryptodev.asym.free) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_free, - lib.cryptodev.asym.free); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_init, + lib.cryptodev.sym.init) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_init, - lib.cryptodev.sym.init); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_init, + lib.cryptodev.asym.init) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_init, - lib.cryptodev.asym.init); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_clear, + lib.cryptodev.sym.clear) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_clear, - lib.cryptodev.sym.clear); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_clear, + lib.cryptodev.asym.clear) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_clear, - lib.cryptodev.asym.clear); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_enqueue_burst, + lib.cryptodev.enq.burst) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_enqueue_burst, - lib.cryptodev.enq.burst); - - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_dequeue_burst, - lib.cryptodev.deq.burst); -} +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_dequeue_burst, + lib.cryptodev.deq.burst) diff --git a/lib/librte_eal/common/eal_common_trace_points.c b/lib/librte_eal/common/eal_common_trace_points.c index 7611977a15..d1d8d1875c 100644 --- a/lib/librte_eal/common/eal_common_trace_points.c +++ b/lib/librte_eal/common/eal_common_trace_points.c @@ -6,110 +6,70 @@ #include <rte_eal_trace.h> -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_void); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u64); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u32); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u16); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u8); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i64); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i32); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i16); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i8); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_int); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_long); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_float); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_double); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_ptr); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_str); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_func); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_void, + lib.eal.generic.void) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u64, + lib.eal.generic.u64) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u32, + lib.eal.generic.u32) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u16, + lib.eal.generic.u16) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u8, + lib.eal.generic.u8) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i64, + lib.eal.generic.i64) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i32, + lib.eal.generic.i32) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i16, + lib.eal.generic.i16) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i8, + lib.eal.generic.i8) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_int, + lib.eal.generic.int) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_long, + lib.eal.generic.long) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_float, + lib.eal.generic.float) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_double, + lib.eal.generic.double) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_ptr, + lib.eal.generic.ptr) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_str, + lib.eal.generic.string) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func, + lib.eal.generic.func) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_alarm_set); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_alarm_cancel); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set, + lib.eal.alarm.set) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_cancel, + lib.eal.alarm.cancel) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_zmalloc); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_malloc); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_realloc); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_free); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_zmalloc, + lib.eal.mem.zmalloc) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_malloc, + lib.eal.mem.malloc) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_realloc, + lib.eal.mem.realloc) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_free, + lib.eal.mem.free) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_memzone_reserve); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_memzone_lookup); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_memzone_free); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_reserve, + lib.eal.memzone.reserve) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_lookup, + lib.eal.memzone.lookup) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_free, + lib.eal.memzone.free) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_thread_remote_launch); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_thread_lcore_ready); +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_DEFINE(rte_eal_trace_intr_callback_register); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_intr_callback_unregister); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_intr_enable); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_intr_disable); - -RTE_INIT(eal_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_void, - lib.eal.generic.void); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u64, - lib.eal.generic.u64); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u32, - lib.eal.generic.u32); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u16, - lib.eal.generic.u16); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u8, - lib.eal.generic.u8); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i64, - lib.eal.generic.i64); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i32, - lib.eal.generic.i32); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i16, - lib.eal.generic.i16); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i8, - lib.eal.generic.i8); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_int, - lib.eal.generic.int); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_long, - lib.eal.generic.long); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_float, - lib.eal.generic.float); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_double, - lib.eal.generic.double); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_ptr, - lib.eal.generic.ptr); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_str, - lib.eal.generic.string); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func, - lib.eal.generic.func); - - RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set, - lib.eal.alarm.set); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_cancel, - lib.eal.alarm.cancel); - - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_zmalloc, - lib.eal.mem.zmalloc); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_malloc, - lib.eal.mem.malloc); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_realloc, - lib.eal.mem.realloc); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_free, - lib.eal.mem.free); - - RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_reserve, - lib.eal.memzone.reserve); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_lookup, - lib.eal.memzone.lookup); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_free, - lib.eal.memzone.free); - - 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_intr_callback_register, - lib.eal.intr.register); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_unregister, - lib.eal.intr.unregister); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_enable, - lib.eal.intr.enable); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_disable, - lib.eal.intr.disable); -} +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_register, + lib.eal.intr.register) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_unregister, + lib.eal.intr.unregister) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_enable, + lib.eal.intr.enable) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_disable, + lib.eal.intr.disable) diff --git a/lib/librte_eal/include/rte_eal_trace.h b/lib/librte_eal/include/rte_eal_trace.h index 1ebb2905a9..923200f054 100644 --- a/lib/librte_eal/include/rte_eal_trace.h +++ b/lib/librte_eal/include/rte_eal_trace.h @@ -19,6 +19,26 @@ extern "C" { #include <rte_interrupts.h> #include <rte_trace_point.h> +/* Alarm */ +RTE_TRACE_POINT( + rte_eal_trace_alarm_set, + RTE_TRACE_POINT_ARGS(uint64_t us, rte_eal_alarm_callback cb_fn, + void *cb_arg, int rc), + rte_trace_point_emit_u64(us); + rte_trace_point_emit_ptr(cb_fn); + rte_trace_point_emit_ptr(cb_arg); + rte_trace_point_emit_int(rc); +) + +RTE_TRACE_POINT( + rte_eal_trace_alarm_cancel, + RTE_TRACE_POINT_ARGS(rte_eal_alarm_callback cb_fn, void *cb_arg, + int count), + rte_trace_point_emit_ptr(cb_fn); + rte_trace_point_emit_ptr(cb_arg); + rte_trace_point_emit_int(count); +) + /* Generic */ RTE_TRACE_POINT( rte_eal_trace_generic_void, @@ -117,24 +137,52 @@ RTE_TRACE_POINT( #define RTE_EAL_TRACE_GENERIC_FUNC rte_eal_trace_generic_func(__func__) -/* Alarm */ +/* Interrupt */ RTE_TRACE_POINT( - rte_eal_trace_alarm_set, - RTE_TRACE_POINT_ARGS(uint64_t us, rte_eal_alarm_callback cb_fn, - void *cb_arg, int rc), - rte_trace_point_emit_u64(us); - rte_trace_point_emit_ptr(cb_fn); - rte_trace_point_emit_ptr(cb_arg); + rte_eal_trace_intr_callback_register, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, + rte_intr_callback_fn cb, void *cb_arg, int rc), rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); + rte_trace_point_emit_ptr(cb); + rte_trace_point_emit_ptr(cb_arg); ) - RTE_TRACE_POINT( - rte_eal_trace_alarm_cancel, - RTE_TRACE_POINT_ARGS(rte_eal_alarm_callback cb_fn, void *cb_arg, - int count), - rte_trace_point_emit_ptr(cb_fn); + rte_eal_trace_intr_callback_unregister, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, + rte_intr_callback_fn cb, void *cb_arg, int rc), + rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); + rte_trace_point_emit_ptr(cb); rte_trace_point_emit_ptr(cb_arg); - rte_trace_point_emit_int(count); +) +RTE_TRACE_POINT( + rte_eal_trace_intr_enable, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), + rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); +) +RTE_TRACE_POINT( + rte_eal_trace_intr_disable, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), + rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); ) /* Memory */ @@ -223,54 +271,6 @@ RTE_TRACE_POINT( rte_trace_point_emit_string(cpuset); ) -/* Interrupt */ -RTE_TRACE_POINT( - rte_eal_trace_intr_callback_register, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, - rte_intr_callback_fn cb, void *cb_arg, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); - rte_trace_point_emit_ptr(cb); - rte_trace_point_emit_ptr(cb_arg); -) -RTE_TRACE_POINT( - rte_eal_trace_intr_callback_unregister, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, - rte_intr_callback_fn cb, void *cb_arg, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); - rte_trace_point_emit_ptr(cb); - rte_trace_point_emit_ptr(cb_arg); -) -RTE_TRACE_POINT( - rte_eal_trace_intr_enable, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); -) -RTE_TRACE_POINT( - rte_eal_trace_intr_disable, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); -) - #ifdef __cplusplus } #endif diff --git a/lib/librte_eal/include/rte_trace_point.h b/lib/librte_eal/include/rte_trace_point.h index 4d956ec164..dbd648c054 100644 --- a/lib/librte_eal/include/rte_trace_point.h +++ b/lib/librte_eal/include/rte_trace_point.h @@ -29,10 +29,6 @@ extern "C" { /** The tracepoint object. */ typedef uint64_t rte_trace_point_t; -/** Macro to define the tracepoint. */ -#define RTE_TRACE_POINT_DEFINE(tp) \ -rte_trace_point_t __attribute__((section("__rte_trace_point"))) __##tp - /** * Macro to define the tracepoint arguments in RTE_TRACE_POINT macro. @@ -64,7 +60,7 @@ _tp _args \ * * @param tp * Tracepoint object. Before using the tracepoint, an application needs to - * define the tracepoint using RTE_TRACE_POINT_DEFINE macro. + * define the tracepoint using RTE_TRACE_POINT_REGISTER macro. * @param args * C function style input arguments to define the arguments to tracepoint * function. @@ -72,7 +68,7 @@ _tp _args \ * Define the payload of trace function. The payload will be formed using * rte_trace_point_emit_* macros. Use ";" delimiter between two payloads. * - * @see RTE_TRACE_POINT_ARGS, RTE_TRACE_POINT_DEFINE, rte_trace_point_emit_* + * @see RTE_TRACE_POINT_ARGS, RTE_TRACE_POINT_REGISTER, rte_trace_point_emit_* */ #define RTE_TRACE_POINT(tp, args, ...) \ __RTE_TRACE_POINT(generic, tp, args, __VA_ARGS__) @@ -85,7 +81,7 @@ _tp _args \ * * @param tp * Tracepoint object. Before using the tracepoint, an application needs to - * define the tracepoint using RTE_TRACE_POINT_DEFINE macro. + * define the tracepoint using RTE_TRACE_POINT_REGISTER macro. * @param args * C function style input arguments to define the arguments to tracepoint. * function. @@ -115,7 +111,7 @@ _tp _args \ * Register a tracepoint. * * @param trace - * The tracepoint object created using RTE_TRACE_POINT_DEFINE. + * The tracepoint object created using RTE_TRACE_POINT_REGISTER. * @param name * The name of the tracepoint object. * @return @@ -262,7 +258,7 @@ void __rte_trace_point_emit_field(size_t sz, const char *field, * Use RTE_TRACE_POINT_REGISTER macro for tracepoint registration. * * @param trace - * The tracepoint object created using RTE_TRACE_POINT_DEFINE. + * The tracepoint object created using RTE_TRACE_POINT_REGISTER. * @param name * The name of the tracepoint object. * @param register_fn diff --git a/lib/librte_eal/include/rte_trace_point_register.h b/lib/librte_eal/include/rte_trace_point_register.h index 4e2306f1af..26e383a8bb 100644 --- a/lib/librte_eal/include/rte_trace_point_register.h +++ b/lib/librte_eal/include/rte_trace_point_register.h @@ -14,8 +14,12 @@ RTE_DECLARE_PER_LCORE(volatile int, trace_point_sz); #define RTE_TRACE_POINT_REGISTER(trace, name) \ +rte_trace_point_t __attribute__((section("__rte_trace_point"))) __##trace; \ +RTE_INIT(trace##_init) \ +{ \ __rte_trace_point_register(&__##trace, RTE_STR(name), \ - (void (*)(void)) trace) + (void (*)(void)) trace); \ +} #define __rte_trace_point_emit_header_generic(t) \ RTE_PER_LCORE(trace_point_sz) = __RTE_TRACE_EVENT_HEADER_SZ diff --git a/lib/librte_ethdev/ethdev_trace_points.c b/lib/librte_ethdev/ethdev_trace_points.c index 05de34f3ca..5be377521c 100644 --- a/lib/librte_ethdev/ethdev_trace_points.c +++ b/lib/librte_ethdev/ethdev_trace_points.c @@ -6,38 +6,26 @@ #include <rte_ethdev_trace.h> -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_configure); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_rxq_setup); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_txq_setup); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_start); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_stop); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_close); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_rx_burst); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_tx_burst); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_configure, + lib.ethdev.configure) -RTE_INIT(ethdev_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_configure, - lib.ethdev.configure); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rxq_setup, + lib.ethdev.rxq.setup) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rxq_setup, - lib.ethdev.rxq.setup); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_txq_setup, + lib.ethdev.txq.setup) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_txq_setup, - lib.ethdev.txq.setup); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_start, + lib.ethdev.start) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_start, - lib.ethdev.start); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_stop, + lib.ethdev.stop) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_stop, - lib.ethdev.stop); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_close, + lib.ethdev.close) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_close, - lib.ethdev.close); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rx_burst, + lib.ethdev.rx.burst) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rx_burst, - lib.ethdev.rx.burst); - - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_tx_burst, - lib.ethdev.tx.burst); -} +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_tx_burst, + lib.ethdev.tx.burst) diff --git a/lib/librte_eventdev/eventdev_trace_points.c b/lib/librte_eventdev/eventdev_trace_points.c index 2aa6e6bcf5..221a62b71c 100644 --- a/lib/librte_eventdev/eventdev_trace_points.c +++ b/lib/librte_eventdev/eventdev_trace_points.c @@ -7,167 +7,114 @@ #include "rte_eventdev_trace.h" /* Eventdev trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_configure); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_queue_setup); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_port_setup); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_port_link); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_port_unlink); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_stop); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_close); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_enq_burst); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_deq_burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_configure, + lib.eventdev.configure) -/* Eventdev Rx adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_queue_add); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_queue_del); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_stop); - -/* Eventdev Tx adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_queue_add); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_queue_del); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_stop); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_enqueue); - -/* Eventdev Timer adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_stop); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_arm_burst); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_arm_tmo_tick_burst); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_cancel_burst); - -/* Eventdev Crypto adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_queue_pair_add); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_queue_pair_del); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_stop); - -RTE_INIT(eventdev_trace_init) -{ - /* Eventdev trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_configure, - lib.eventdev.configure); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_queue_setup, + lib.eventdev.queue.setup) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_queue_setup, - lib.eventdev.queue.setup); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_setup, + lib.eventdev.port.setup) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_setup, - lib.eventdev.port.setup); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_link, + lib.eventdev.port.link) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_link, - lib.eventdev.port.link); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_unlink, + lib.eventdev.port.unlink) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_unlink, - lib.eventdev.port.unlink); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_start, + lib.eventdev.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_start, - lib.eventdev.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_stop, + lib.eventdev.stop) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_stop, - lib.eventdev.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_close, + lib.eventdev.close) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_close, - lib.eventdev.close); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_enq_burst, + lib.eventdev.enq.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_enq_burst, - lib.eventdev.enq.burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_deq_burst, + lib.eventdev.deq.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_deq_burst, - lib.eventdev.deq.burst); - - - /* Eventdev Rx adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_create, - lib.eventdev.rx.adapter.create); - - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_free, - lib.eventdev.rx.adapter.free); +/* Eventdev Rx adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_create, + lib.eventdev.rx.adapter.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_add, - lib.eventdev.rx.adapter.queue.add); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_free, + lib.eventdev.rx.adapter.free) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_del, - lib.eventdev.rx.adapter.queue.del); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_add, + lib.eventdev.rx.adapter.queue.add) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_start, - lib.eventdev.rx.adapter.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_del, + lib.eventdev.rx.adapter.queue.del) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_stop, - lib.eventdev.rx.adapter.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_start, + lib.eventdev.rx.adapter.start) - /* Eventdev Tx adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_create, - lib.eventdev.tx.adapter.create); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_stop, + lib.eventdev.rx.adapter.stop) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_free, - lib.eventdev.tx.adapter.free); +/* Eventdev Tx adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_create, + lib.eventdev.tx.adapter.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_add, - lib.eventdev.tx.adapter.queue.add); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_free, + lib.eventdev.tx.adapter.free) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_del, - lib.eventdev.tx.adapter.queue.del); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_add, + lib.eventdev.tx.adapter.queue.add) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_start, - lib.eventdev.tx.adapter.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_del, + lib.eventdev.tx.adapter.queue.del) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_stop, - lib.eventdev.tx.adapter.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_start, + lib.eventdev.tx.adapter.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_enqueue, - lib.eventdev.tx.adapter.enq); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_stop, + lib.eventdev.tx.adapter.stop) +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_enqueue, + lib.eventdev.tx.adapter.enq) - /* Eventdev Timer adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_create, - lib.eventdev.timer.create); +/* Eventdev Timer adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_create, + lib.eventdev.timer.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_start, - lib.eventdev.timer.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_start, + lib.eventdev.timer.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_stop, - lib.eventdev.timer.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_stop, + lib.eventdev.timer.stop) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_free, - lib.eventdev.timer.free); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_free, + lib.eventdev.timer.free) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_burst, - lib.eventdev.timer.burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_burst, + lib.eventdev.timer.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_tmo_tick_burst, - lib.eventdev.timer.tick.burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_tmo_tick_burst, + lib.eventdev.timer.tick.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_cancel_burst, - lib.eventdev.timer.cancel); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_cancel_burst, + lib.eventdev.timer.cancel) - /* Eventdev Crypto adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_create, - lib.eventdev.crypto.create); +/* Eventdev Crypto adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_create, + lib.eventdev.crypto.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_free, - lib.eventdev.crypto.free); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_free, + lib.eventdev.crypto.free) - RTE_TRACE_POINT_REGISTER( - rte_eventdev_trace_crypto_adapter_queue_pair_add, - lib.eventdev.crypto.queue.add); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_queue_pair_add, + lib.eventdev.crypto.queue.add) - RTE_TRACE_POINT_REGISTER( - rte_eventdev_trace_crypto_adapter_queue_pair_del, - lib.eventdev.crypto.queue.del); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_queue_pair_del, + lib.eventdev.crypto.queue.del) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_start, - lib.eventdev.crypto.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_start, + lib.eventdev.crypto.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_stop, - lib.eventdev.crypto.stop); -} +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_stop, + lib.eventdev.crypto.stop) diff --git a/lib/librte_mempool/mempool_trace_points.c b/lib/librte_mempool/mempool_trace_points.c index afab8dff68..3dac0bc536 100644 --- a/lib/librte_mempool/mempool_trace_points.c +++ b/lib/librte_mempool/mempool_trace_points.c @@ -6,102 +6,74 @@ #include "rte_mempool_trace.h" -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_dequeue_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_dequeue_contig_blocks); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_enqueue_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_generic_put); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_put_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_generic_get); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_get_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_get_contig_blocks); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_create); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_create_empty); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_free); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_iova); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_virt); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_default); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_anon); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_cache_create); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_cache_free); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_default_cache); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_get_page_size); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_cache_flush); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_populate); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_alloc); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_free); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_set_ops_byname); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_bulk, + lib.mempool.ops.deq.bulk) -RTE_INIT(mempool_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_bulk, - lib.mempool.ops.deq.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_contig_blocks, + lib.mempool.ops.deq.contig) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_contig_blocks, - lib.mempool.ops.deq.contig); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_enqueue_bulk, + lib.mempool.ops.enq.bulk) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_enqueue_bulk, - lib.mempool.ops.enq.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_put, + lib.mempool.generic.put) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_put, - lib.mempool.generic.put); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_put_bulk, + lib.mempool.put.bulk) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_put_bulk, - lib.mempool.put.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_get, + lib.mempool.generic.get) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_get, - lib.mempool.generic.get); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_bulk, + lib.mempool.get.bulk) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_bulk, - lib.mempool.get.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_contig_blocks, + lib.mempool.get.blocks) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_contig_blocks, - lib.mempool.get.blocks); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create, + lib.mempool.create) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create, - lib.mempool.create); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create_empty, + lib.mempool.create.empty) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create_empty, - lib.mempool.create.empty); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_free, + lib.mempool.free) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_free, - lib.mempool.free); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_iova, + lib.mempool.populate.iova) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_iova, - lib.mempool.populate.iova); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_virt, + lib.mempool.populate.virt) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_virt, - lib.mempool.populate.virt); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_default, + lib.mempool.populate.default) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_default, - lib.mempool.populate.default); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_anon, + lib.mempool.populate.anon) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_anon, - lib.mempool.populate.anon); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_create, + lib.mempool.cache_create) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_create, - lib.mempool.cache_create); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_free, + lib.mempool.cache.free) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_free, - lib.mempool.cache.free); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_default_cache, + lib.mempool.default.cache) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_default_cache, - lib.mempool.default.cache); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_page_size, + lib.mempool.get.page.size) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_page_size, - lib.mempool.get.page.size); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_flush, + lib.mempool.cache.flush) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_flush, - lib.mempool.cache.flush); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_populate, + lib.mempool.ops.populate) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_populate, - lib.mempool.ops.populate); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_alloc, + lib.mempool.ops.alloc) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_alloc, - lib.mempool.ops.alloc); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_free, + lib.mempool.ops.free) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_free, - lib.mempool.ops.free); - - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_set_ops_byname, - lib.mempool.set.ops.byname); -} +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_set_ops_byname, + lib.mempool.set.ops.byname) -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-03 20:31 ` [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration David Marchand @ 2020-05-04 2:46 ` Jerin Jacob 2020-05-04 14:02 ` Thomas Monjalon 2020-05-04 14:04 ` David Marchand 2020-07-04 14:31 ` Jerin Jacob 2020-07-04 15:14 ` [dpdk-dev] [PATCH v2] " David Marchand 2 siblings, 2 replies; 55+ messages in thread From: Jerin Jacob @ 2020-05-04 2:46 UTC (permalink / raw) To: David Marchand Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. Initially, I thought of doing the same. But, later I realized that this largely grows the number of constructors been called. I had concerns about the boot time of the application and/or loading the shared library, that the reason why spitting as two so that constructor registers a burst of traces like rte_log. > > Signed-off-by: David Marchand <david.marchand@redhat.com> > --- > app/test/test_trace_register.c | 12 +- > doc/guides/prog_guide/trace_lib.rst | 12 +- > lib/librte_cryptodev/cryptodev_trace_points.c | 84 +++---- > .../common/eal_common_trace_points.c | 164 ++++++-------- > lib/librte_eal/include/rte_eal_trace.h | 122 +++++------ > lib/librte_eal/include/rte_trace_point.h | 14 +- > .../include/rte_trace_point_register.h | 6 +- > lib/librte_ethdev/ethdev_trace_points.c | 44 ++-- > lib/librte_eventdev/eventdev_trace_points.c | 205 +++++++----------- > lib/librte_mempool/mempool_trace_points.c | 124 ++++------- > 10 files changed, 309 insertions(+), 478 deletions(-) ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 2:46 ` Jerin Jacob @ 2020-05-04 14:02 ` Thomas Monjalon 2020-05-04 14:04 ` David Marchand 1 sibling, 0 replies; 55+ messages in thread From: Thomas Monjalon @ 2020-05-04 14:02 UTC (permalink / raw) To: Jerin Jacob Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 04/05/2020 04:46, Jerin Jacob: > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > Initially, I thought of doing the same. But, later I realized that > this largely grows the number of constructors been called. > I had concerns about the boot time of the application and/or loading > the shared library, that the reason why spitting > as two so that constructor registers a burst of traces like rte_log. I don't understand the concern. How adding more constructors is affecting the library load time? Do you have any number? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 2:46 ` Jerin Jacob 2020-05-04 14:02 ` Thomas Monjalon @ 2020-05-04 14:04 ` David Marchand 2020-05-04 14:39 ` Jerin Jacob 1 sibling, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-04 14:04 UTC (permalink / raw) To: Jerin Jacob Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > Initially, I thought of doing the same. But, later I realized that > this largely grows the number of constructors been called. > I had concerns about the boot time of the application and/or loading > the shared library, that the reason why spitting > as two so that constructor registers a burst of traces like rte_log. I am a bit skeptical. In terms of cycles and looking at __rte_trace_point_register() (which calls malloc), the cost of calling multiple constructors instead of one is negligible. -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 14:04 ` David Marchand @ 2020-05-04 14:39 ` Jerin Jacob 2020-05-04 17:08 ` David Marchand 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-04 14:39 UTC (permalink / raw) To: David Marchand Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > Initially, I thought of doing the same. But, later I realized that > > this largely grows the number of constructors been called. > > I had concerns about the boot time of the application and/or loading > > the shared library, that the reason why spitting > > as two so that constructor registers a burst of traces like rte_log. > > I am a bit skeptical. > In terms of cycles and looking at __rte_trace_point_register() (which > calls malloc), the cost of calling multiple constructors instead of > one is negligible. We will have a lot tracepoints latter, each one translates to the constructor may not be a good improvement. The scope is limited only to register function so IMO it is okay to have split just like rte_log. I don't see any reason why it has to be a different than rte_log. One of the thought process is, we probably remove the constructor scheme to all other with DPDK and replace it with a more register scheme. In such a case, we can skip calling the constructor all tother when trace is disabled. > > > -- > David Marchand > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 14:39 ` Jerin Jacob @ 2020-05-04 17:08 ` David Marchand 2020-05-04 17:19 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-04 17:08 UTC (permalink / raw) To: Jerin Jacob Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > this largely grows the number of constructors been called. > > > I had concerns about the boot time of the application and/or loading > > > the shared library, that the reason why spitting > > > as two so that constructor registers a burst of traces like rte_log. > > > > I am a bit skeptical. > > In terms of cycles and looking at __rte_trace_point_register() (which > > calls malloc), the cost of calling multiple constructors instead of > > one is negligible. > > We will have a lot tracepoints latter, each one translates to the > constructor may not be a good > improvement. The scope is limited only to register function so IMO it > is okay to have split > just like rte_log. I don't see any reason why it has to be a different > than rte_log. What is similar to rte_log? There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of dynamic logtypes. > > One of the thought process is, we probably remove the constructor > scheme to all other with DPDK > and replace it with a more register scheme. In such a case, we can > skip calling the constructor all tother > when trace is disabled. Sorry, but I have a hard time understanding your point. Are you talking about application boot time? -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 17:08 ` David Marchand @ 2020-05-04 17:19 ` Jerin Jacob 2020-05-04 17:40 ` David Marchand 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-04 17:19 UTC (permalink / raw) To: David Marchand Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 10:38 PM David Marchand <david.marchand@redhat.com> wrote: > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > this largely grows the number of constructors been called. > > > > I had concerns about the boot time of the application and/or loading > > > > the shared library, that the reason why spitting > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > I am a bit skeptical. > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > calls malloc), the cost of calling multiple constructors instead of > > > one is negligible. > > > > We will have a lot tracepoints latter, each one translates to the > > constructor may not be a good > > improvement. The scope is limited only to register function so IMO it > > is okay to have split > > just like rte_log. I don't see any reason why it has to be a different > > than rte_log. > > What is similar to rte_log? > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > dynamic logtypes. Here is an example of rte_log registration. Which has _one_ constructor and N number of rte_log_register() underneath. 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); } > > > > > > One of the thought process is, we probably remove the constructor > > scheme to all other with DPDK > > and replace it with a more register scheme. In such a case, we can > > skip calling the constructor all tother > > when trace is disabled. > > Sorry, but I have a hard time understanding your point. > Are you talking about application boot time? Yes. The optimization of application boottime time in case of static binary and/or shared library(.so) load time. > > > -- > David Marchand > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 17:19 ` Jerin Jacob @ 2020-05-04 17:40 ` David Marchand 2020-05-04 17:54 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-04 17:40 UTC (permalink / raw) To: Jerin Jacob Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Mon, May 4, 2020 at 10:38 PM David Marchand > <david.marchand@redhat.com> wrote: > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > this largely grows the number of constructors been called. > > > > > I had concerns about the boot time of the application and/or loading > > > > > the shared library, that the reason why spitting > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > I am a bit skeptical. > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > calls malloc), the cost of calling multiple constructors instead of > > > > one is negligible. > > > > > > We will have a lot tracepoints latter, each one translates to the > > > constructor may not be a good > > > improvement. The scope is limited only to register function so IMO it > > > is okay to have split > > > just like rte_log. I don't see any reason why it has to be a different > > > than rte_log. > > > > What is similar to rte_log? > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > dynamic logtypes. > > > Here is an example of rte_log registration. Which has _one_ > constructor and N number of > rte_log_register() underneath. rte_log is one thing, rte_trace is already different. There is _no macro_ in rte_log for registration. The reason being in that a rte_log logtype is a simple integer without any special declaration requiring a macro. For tracepoints, we have a special two steps thing: the tracepoint handle must be derived from the tracepoint name. Then this handle must be registered. What I proposed is to make life easier for developers that want to add tracepoints and I suppose you noticed patch 1 of this series. > > > One of the thought process is, we probably remove the constructor > > > scheme to all other with DPDK > > > and replace it with a more register scheme. In such a case, we can > > > skip calling the constructor all tother > > > when trace is disabled. > > > > Sorry, but I have a hard time understanding your point. > > Are you talking about application boot time? > > Yes. The optimization of application boottime time in case of static > binary and/or shared library(.so) load time. As Thomas mentioned, do you have numbers? -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 17:40 ` David Marchand @ 2020-05-04 17:54 ` Jerin Jacob 2020-05-04 21:31 ` Thomas Monjalon 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-04 17:54 UTC (permalink / raw) To: David Marchand Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 11:10 PM David Marchand <david.marchand@redhat.com> wrote: > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > <david.marchand@redhat.com> wrote: > > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > this largely grows the number of constructors been called. > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > the shared library, that the reason why spitting > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > I am a bit skeptical. > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > one is negligible. > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > constructor may not be a good > > > > improvement. The scope is limited only to register function so IMO it > > > > is okay to have split > > > > just like rte_log. I don't see any reason why it has to be a different > > > > than rte_log. > > > > > > What is similar to rte_log? > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > dynamic logtypes. > > > > > > Here is an example of rte_log registration. Which has _one_ > > constructor and N number of > > rte_log_register() underneath. > > rte_log is one thing, rte_trace is already different. > > There is _no macro_ in rte_log for registration. > The reason being in that a rte_log logtype is a simple integer without > any special declaration requiring a macro. I just wrapped in macro for convincing, but it has the same semantics. global variable and API/macro to register. > > For tracepoints, we have a special two steps thing: the tracepoint > handle must be derived from the tracepoint name. > Then this handle must be registered. > What I proposed is to make life easier for developers that want to add > tracepoints and I suppose you noticed patch 1 of this series. To reduce the constructors. I don't want trace libraries to add lot of constructors. I don't think it simplifies a lot as the scope of only for registration. > > > > > > One of the thought process is, we probably remove the constructor > > > > scheme to all other with DPDK > > > > and replace it with a more register scheme. In such a case, we can > > > > skip calling the constructor all tother > > > > when trace is disabled. > > > > > > Sorry, but I have a hard time understanding your point. > > > Are you talking about application boot time? > > > > Yes. The optimization of application boottime time in case of static > > binary and/or shared library(.so) load time. > > As Thomas mentioned, do you have numbers? No. But I know, it is obvious that current code is better in terms of boot time than the proposed one. I would like to not add a lot of constructor for trace as the FIRST module in DPDK. > > > -- > David Marchand > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 17:54 ` Jerin Jacob @ 2020-05-04 21:31 ` Thomas Monjalon 2020-05-05 3:43 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-04 21:31 UTC (permalink / raw) To: Jerin Jacob Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 04/05/2020 19:54, Jerin Jacob: > On Mon, May 4, 2020 at 11:10 PM David Marchand > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > this largely grows the number of constructors been called. > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > the shared library, that the reason why spitting > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > I am a bit skeptical. > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > one is negligible. > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > constructor may not be a good > > > > > improvement. The scope is limited only to register function so IMO it > > > > > is okay to have split > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > than rte_log. > > > > > > > > What is similar to rte_log? > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > dynamic logtypes. > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > constructor and N number of > > > rte_log_register() underneath. > > > > rte_log is one thing, rte_trace is already different. > > > > There is _no macro_ in rte_log for registration. > > The reason being in that a rte_log logtype is a simple integer without > > any special declaration requiring a macro. > > I just wrapped in macro for convincing, but it has the same semantics. > global variable and API/macro to register. > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > handle must be derived from the tracepoint name. > > Then this handle must be registered. > > What I proposed is to make life easier for developers that want to add > > tracepoints and I suppose you noticed patch 1 of this series. > > To reduce the constructors. I don't want trace libraries to add lot of > constructors. > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > scheme to all other with DPDK > > > > > and replace it with a more register scheme. In such a case, we can > > > > > skip calling the constructor all tother > > > > > when trace is disabled. > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > Are you talking about application boot time? > > > > > > Yes. The optimization of application boottime time in case of static > > > binary and/or shared library(.so) load time. > > > > As Thomas mentioned, do you have numbers? > > No. But I know, it is obvious that current code is better in terms of > boot time than the proposed one. > I would like to not add a lot of constructor for trace as the FIRST > module in DPDK. No, it is not obvious. The version from David looks simpler to use and to understand. Without any number, I consider usability (and maintenance) wins. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-04 21:31 ` Thomas Monjalon @ 2020-05-05 3:43 ` Jerin Jacob 2020-05-05 7:01 ` Thomas Monjalon 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 3:43 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 3:01 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > 04/05/2020 19:54, Jerin Jacob: > > On Mon, May 4, 2020 at 11:10 PM David Marchand > > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > > this largely grows the number of constructors been called. > > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > > the shared library, that the reason why spitting > > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > > > I am a bit skeptical. > > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > > one is negligible. > > > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > > constructor may not be a good > > > > > > improvement. The scope is limited only to register function so IMO it > > > > > > is okay to have split > > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > > than rte_log. > > > > > > > > > > What is similar to rte_log? > > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > > dynamic logtypes. > > > > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > > constructor and N number of > > > > rte_log_register() underneath. > > > > > > rte_log is one thing, rte_trace is already different. > > > > > > There is _no macro_ in rte_log for registration. > > > The reason being in that a rte_log logtype is a simple integer without > > > any special declaration requiring a macro. > > > > I just wrapped in macro for convincing, but it has the same semantics. > > global variable and API/macro to register. > > > > > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > > handle must be derived from the tracepoint name. > > > Then this handle must be registered. > > > What I proposed is to make life easier for developers that want to add > > > tracepoints and I suppose you noticed patch 1 of this series. > > > > To reduce the constructors. I don't want trace libraries to add lot of > > constructors. > > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > > scheme to all other with DPDK > > > > > > and replace it with a more register scheme. In such a case, we can > > > > > > skip calling the constructor all tother > > > > > > when trace is disabled. > > > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > > Are you talking about application boot time? > > > > > > > > Yes. The optimization of application boottime time in case of static > > > > binary and/or shared library(.so) load time. > > > > > > As Thomas mentioned, do you have numbers? > > > > No. But I know, it is obvious that current code is better in terms of > > boot time than the proposed one. > > I would like to not add a lot of constructor for trace as the FIRST > > module in DPDK. > > No, it is not obvious. > The version from David looks simpler to use and to understand. > Without any number, I consider usability (and maintenance) wins. Thanks for the feedback. As the trace maintainer, I would like not to explode constructor usage for trace library. My reasoning, We could do trace registration without this constructor scheme. If you think, it is better usability, lets add an option for rte_log for the constructor scheme. Analyze the impact wrt boot time and cross-platform pov as the log has a lot of entries to test. If the usage makes sense then it should make sense for rte_log too. I would like to NOT have trace to be the first library to explode with the constructor scheme. I suggest removing this specific patch from RC2 and revisit later. > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 3:43 ` Jerin Jacob @ 2020-05-05 7:01 ` Thomas Monjalon 2020-05-05 7:17 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-05 7:01 UTC (permalink / raw) To: Jerin Jacob Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 05/05/2020 05:43, Jerin Jacob: > On Tue, May 5, 2020 at 3:01 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > 04/05/2020 19:54, Jerin Jacob: > > > On Mon, May 4, 2020 at 11:10 PM David Marchand > > > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > > > this largely grows the number of constructors been called. > > > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > > > the shared library, that the reason why spitting > > > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > > > > > I am a bit skeptical. > > > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > > > one is negligible. > > > > > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > > > constructor may not be a good > > > > > > > improvement. The scope is limited only to register function so IMO it > > > > > > > is okay to have split > > > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > > > than rte_log. > > > > > > > > > > > > What is similar to rte_log? > > > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > > > dynamic logtypes. > > > > > > > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > > > constructor and N number of > > > > > rte_log_register() underneath. > > > > > > > > rte_log is one thing, rte_trace is already different. > > > > > > > > There is _no macro_ in rte_log for registration. > > > > The reason being in that a rte_log logtype is a simple integer without > > > > any special declaration requiring a macro. > > > > > > I just wrapped in macro for convincing, but it has the same semantics. > > > global variable and API/macro to register. > > > > > > > > > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > > > handle must be derived from the tracepoint name. > > > > Then this handle must be registered. > > > > What I proposed is to make life easier for developers that want to add > > > > tracepoints and I suppose you noticed patch 1 of this series. > > > > > > To reduce the constructors. I don't want trace libraries to add lot of > > > constructors. > > > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > > > scheme to all other with DPDK > > > > > > > and replace it with a more register scheme. In such a case, we can > > > > > > > skip calling the constructor all tother > > > > > > > when trace is disabled. > > > > > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > > > Are you talking about application boot time? > > > > > > > > > > Yes. The optimization of application boottime time in case of static > > > > > binary and/or shared library(.so) load time. > > > > > > > > As Thomas mentioned, do you have numbers? > > > > > > No. But I know, it is obvious that current code is better in terms of > > > boot time than the proposed one. > > > I would like to not add a lot of constructor for trace as the FIRST > > > module in DPDK. > > > > No, it is not obvious. > > The version from David looks simpler to use and to understand. > > Without any number, I consider usability (and maintenance) wins. > > Thanks for the feedback. > > As the trace maintainer, I would like not to explode constructor usage > for trace library. > My reasoning, We could do trace registration without this constructor scheme. ??? > If you think, it is better usability, lets add an option for rte_log > for the constructor scheme. It makes non-sense. rte_log requires only one function call per log type. rte_trace requires 3 macros calls per trace type: RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS This patch is unifying the first 2 macro calls to make usage simpler, and ease rte_trace adoption. Note: the other usability weirdness is mandating declaring each trace function with a magic double underscore prefix which appears nowhere else. > Analyze the impact wrt boot time and cross-platform pov as the log > has a lot of entries to test. If the usage makes sense then it should make sense > for rte_log too. I would like to NOT have trace to be the first > library to explode > with the constructor scheme. I suggest removing this specific patch from RC2 and > revisit later. You still did not give any argument against increasing the number of constructors. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 7:01 ` Thomas Monjalon @ 2020-05-05 7:17 ` Jerin Jacob 2020-05-05 7:24 ` Thomas Monjalon 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 7:17 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 12:31 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 05:43, Jerin Jacob: > > On Tue, May 5, 2020 at 3:01 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > > 04/05/2020 19:54, Jerin Jacob: > > > > On Mon, May 4, 2020 at 11:10 PM David Marchand > > > > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > > > > this largely grows the number of constructors been called. > > > > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > > > > the shared library, that the reason why spitting > > > > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > > > > > > > I am a bit skeptical. > > > > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > > > > one is negligible. > > > > > > > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > > > > constructor may not be a good > > > > > > > > improvement. The scope is limited only to register function so IMO it > > > > > > > > is okay to have split > > > > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > > > > than rte_log. > > > > > > > > > > > > > > What is similar to rte_log? > > > > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > > > > dynamic logtypes. > > > > > > > > > > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > > > > constructor and N number of > > > > > > rte_log_register() underneath. > > > > > > > > > > rte_log is one thing, rte_trace is already different. > > > > > > > > > > There is _no macro_ in rte_log for registration. > > > > > The reason being in that a rte_log logtype is a simple integer without > > > > > any special declaration requiring a macro. > > > > > > > > I just wrapped in macro for convincing, but it has the same semantics. > > > > global variable and API/macro to register. > > > > > > > > > > > > > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > > > > handle must be derived from the tracepoint name. > > > > > Then this handle must be registered. > > > > > What I proposed is to make life easier for developers that want to add > > > > > tracepoints and I suppose you noticed patch 1 of this series. > > > > > > > > To reduce the constructors. I don't want trace libraries to add lot of > > > > constructors. > > > > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > > > > > > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > > > > scheme to all other with DPDK > > > > > > > > and replace it with a more register scheme. In such a case, we can > > > > > > > > skip calling the constructor all tother > > > > > > > > when trace is disabled. > > > > > > > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > > > > Are you talking about application boot time? > > > > > > > > > > > > Yes. The optimization of application boottime time in case of static > > > > > > binary and/or shared library(.so) load time. > > > > > > > > > > As Thomas mentioned, do you have numbers? > > > > > > > > No. But I know, it is obvious that current code is better in terms of > > > > boot time than the proposed one. > > > > I would like to not add a lot of constructor for trace as the FIRST > > > > module in DPDK. > > > > > > No, it is not obvious. > > > The version from David looks simpler to use and to understand. > > > Without any number, I consider usability (and maintenance) wins. > > > > Thanks for the feedback. > > > > As the trace maintainer, I would like not to explode constructor usage > > for trace library. > > My reasoning, We could do trace registration without this constructor scheme. > ??? We don't need this patch to make trace to work. > > > > If you think, it is better usability, lets add an option for rte_log > > for the constructor scheme. > > It makes non-sense. > rte_log requires only one function call per log type. Here is the example of the log registration: global variable: int otx2_logtype_base; int otx2_logtype_mbox; int otx2_logtype_npa; RTE_INIT(otx2_log_init); static void otx2_log_init(void) { otx2_logtype_base = rte_log_register("pmd.octeontx2.base"); otx2_logtype_mbox = rte_log_register("pmd.octeontx2.mbox"); otx2_logtype_npa = rte_log_register("pmd.mempool.octeontx2"); } What the proposed patch here. # Making N constructors from one # Grouping global variable and register function under a single Marco and making it as N constructors. Why can we do the same logic for rte_log? > rte_trace requires 3 macros calls per trace type: > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > This patch is unifying the first 2 macro calls to make usage simpler, > and ease rte_trace adoption. RTE_TRACE_POINT_ARGS is NOP and for the syntax. It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead it is creating global variable see, "int otx2_logtype_base; > > Note: the other usability weirdness is mandating declaring each trace > function with a magic double underscore prefix which appears nowhere else. > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > has a lot of entries to test. If the usage makes sense then it should make sense > > for rte_log too. I would like to NOT have trace to be the first > > library to explode > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > revisit later. > > You still did not give any argument against increasing the number > of constructors. If you are proposing the new scheme, you have to prove the overhead with a significant number of constructors and why it has differed from existing scheme of things. That's is the norm in opensource. > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 7:17 ` Jerin Jacob @ 2020-05-05 7:24 ` Thomas Monjalon 2020-05-05 7:33 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-05 7:24 UTC (permalink / raw) To: Jerin Jacob Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 05/05/2020 09:17, Jerin Jacob: > On Tue, May 5, 2020 at 12:31 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 05:43, Jerin Jacob: > > > On Tue, May 5, 2020 at 3:01 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > 04/05/2020 19:54, Jerin Jacob: > > > > > On Mon, May 4, 2020 at 11:10 PM David Marchand > > > > > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > > > > > this largely grows the number of constructors been called. > > > > > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > > > > > the shared library, that the reason why spitting > > > > > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > > > > > > > > > I am a bit skeptical. > > > > > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > > > > > one is negligible. > > > > > > > > > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > > > > > constructor may not be a good > > > > > > > > > improvement. The scope is limited only to register function so IMO it > > > > > > > > > is okay to have split > > > > > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > > > > > than rte_log. > > > > > > > > > > > > > > > > What is similar to rte_log? > > > > > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > > > > > dynamic logtypes. > > > > > > > > > > > > > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > > > > > constructor and N number of > > > > > > > rte_log_register() underneath. > > > > > > > > > > > > rte_log is one thing, rte_trace is already different. > > > > > > > > > > > > There is _no macro_ in rte_log for registration. > > > > > > The reason being in that a rte_log logtype is a simple integer without > > > > > > any special declaration requiring a macro. > > > > > > > > > > I just wrapped in macro for convincing, but it has the same semantics. > > > > > global variable and API/macro to register. > > > > > > > > > > > > > > > > > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > > > > > handle must be derived from the tracepoint name. > > > > > > Then this handle must be registered. > > > > > > What I proposed is to make life easier for developers that want to add > > > > > > tracepoints and I suppose you noticed patch 1 of this series. > > > > > > > > > > To reduce the constructors. I don't want trace libraries to add lot of > > > > > constructors. > > > > > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > > > > > scheme to all other with DPDK > > > > > > > > > and replace it with a more register scheme. In such a case, we can > > > > > > > > > skip calling the constructor all tother > > > > > > > > > when trace is disabled. > > > > > > > > > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > > > > > Are you talking about application boot time? > > > > > > > > > > > > > > Yes. The optimization of application boottime time in case of static > > > > > > > binary and/or shared library(.so) load time. > > > > > > > > > > > > As Thomas mentioned, do you have numbers? > > > > > > > > > > No. But I know, it is obvious that current code is better in terms of > > > > > boot time than the proposed one. > > > > > I would like to not add a lot of constructor for trace as the FIRST > > > > > module in DPDK. > > > > > > > > No, it is not obvious. > > > > The version from David looks simpler to use and to understand. > > > > Without any number, I consider usability (and maintenance) wins. > > > > > > Thanks for the feedback. > > > > > > As the trace maintainer, I would like not to explode constructor usage > > > for trace library. > > > My reasoning, We could do trace registration without this constructor scheme. > > ??? > > We don't need this patch to make trace to work. > > > > > > > > If you think, it is better usability, lets add an option for rte_log > > > for the constructor scheme. > > > > It makes non-sense. > > rte_log requires only one function call per log type. > > Here is the example of the log registration: > > global variable: > int otx2_logtype_base; > int otx2_logtype_mbox; > int otx2_logtype_npa; > > RTE_INIT(otx2_log_init); > static void > otx2_log_init(void) > { > otx2_logtype_base = rte_log_register("pmd.octeontx2.base"); > otx2_logtype_mbox = rte_log_register("pmd.octeontx2.mbox"); > otx2_logtype_npa = rte_log_register("pmd.mempool.octeontx2"); > } > > What the proposed patch here. > # Making N constructors from one > # Grouping global variable and register function under a single Marco > and making it as N constructors. > Why can we do the same logic for rte_log? rte_log is simple, there is nothing to simplify. This comparison makes no sense. > > rte_trace requires 3 macros calls per trace type: > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > This patch is unifying the first 2 macro calls to make usage simpler, > > and ease rte_trace adoption. > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > it is creating global variable see, "int otx2_logtype_base; > > > > > Note: the other usability weirdness is mandating declaring each trace > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > for rte_log too. I would like to NOT have trace to be the first > > > library to explode > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > revisit later. > > > > You still did not give any argument against increasing the number > > of constructors. > > If you are proposing the new scheme, you have to prove the overhead > with a significant number of constructors > and why it has differed from existing scheme of things. That's is the > norm in opensource. I say there is no overhead. The target is to simplify the usage and I prove it: 1 call replacing 2 calls. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 7:24 ` Thomas Monjalon @ 2020-05-05 7:33 ` Jerin Jacob 2020-05-05 8:23 ` David Marchand 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 7:33 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 12:55 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 09:17, Jerin Jacob: > > On Tue, May 5, 2020 at 12:31 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > 05/05/2020 05:43, Jerin Jacob: > > > > On Tue, May 5, 2020 at 3:01 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > > 04/05/2020 19:54, Jerin Jacob: > > > > > > On Mon, May 4, 2020 at 11:10 PM David Marchand > > > > > > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > > > > > > this largely grows the number of constructors been called. > > > > > > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > > > > > > the shared library, that the reason why spitting > > > > > > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > > > > > > > > > > > I am a bit skeptical. > > > > > > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > > > > > > one is negligible. > > > > > > > > > > > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > > > > > > constructor may not be a good > > > > > > > > > > improvement. The scope is limited only to register function so IMO it > > > > > > > > > > is okay to have split > > > > > > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > > > > > > than rte_log. > > > > > > > > > > > > > > > > > > What is similar to rte_log? > > > > > > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > > > > > > dynamic logtypes. > > > > > > > > > > > > > > > > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > > > > > > constructor and N number of > > > > > > > > rte_log_register() underneath. > > > > > > > > > > > > > > rte_log is one thing, rte_trace is already different. > > > > > > > > > > > > > > There is _no macro_ in rte_log for registration. > > > > > > > The reason being in that a rte_log logtype is a simple integer without > > > > > > > any special declaration requiring a macro. > > > > > > > > > > > > I just wrapped in macro for convincing, but it has the same semantics. > > > > > > global variable and API/macro to register. > > > > > > > > > > > > > > > > > > > > > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > > > > > > handle must be derived from the tracepoint name. > > > > > > > Then this handle must be registered. > > > > > > > What I proposed is to make life easier for developers that want to add > > > > > > > tracepoints and I suppose you noticed patch 1 of this series. > > > > > > > > > > > > To reduce the constructors. I don't want trace libraries to add lot of > > > > > > constructors. > > > > > > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > > > > > > scheme to all other with DPDK > > > > > > > > > > and replace it with a more register scheme. In such a case, we can > > > > > > > > > > skip calling the constructor all tother > > > > > > > > > > when trace is disabled. > > > > > > > > > > > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > > > > > > Are you talking about application boot time? > > > > > > > > > > > > > > > > Yes. The optimization of application boottime time in case of static > > > > > > > > binary and/or shared library(.so) load time. > > > > > > > > > > > > > > As Thomas mentioned, do you have numbers? > > > > > > > > > > > > No. But I know, it is obvious that current code is better in terms of > > > > > > boot time than the proposed one. > > > > > > I would like to not add a lot of constructor for trace as the FIRST > > > > > > module in DPDK. > > > > > > > > > > No, it is not obvious. > > > > > The version from David looks simpler to use and to understand. > > > > > Without any number, I consider usability (and maintenance) wins. > > > > > > > > Thanks for the feedback. > > > > > > > > As the trace maintainer, I would like not to explode constructor usage > > > > for trace library. > > > > My reasoning, We could do trace registration without this constructor scheme. > > > ??? > > > > We don't need this patch to make trace to work. > > > > > > > > > > > > If you think, it is better usability, lets add an option for rte_log > > > > for the constructor scheme. > > > > > > It makes non-sense. > > > rte_log requires only one function call per log type. > > > > Here is the example of the log registration: > > > > global variable: > > int otx2_logtype_base; > > int otx2_logtype_mbox; > > int otx2_logtype_npa; > > > > RTE_INIT(otx2_log_init); > > static void > > otx2_log_init(void) > > { > > otx2_logtype_base = rte_log_register("pmd.octeontx2.base"); > > otx2_logtype_mbox = rte_log_register("pmd.octeontx2.mbox"); > > otx2_logtype_npa = rte_log_register("pmd.mempool.octeontx2"); > > } > > > > What the proposed patch here. > > # Making N constructors from one > > # Grouping global variable and register function under a single Marco > > and making it as N constructors. > > Why can we do the same logic for rte_log? > > rte_log is simple, there is nothing to simplify. Why not make, rte_log_register() and the global variable under a macro? That's something done by the proposed patch. > > This comparison makes no sense. > > > > > rte_trace requires 3 macros calls per trace type: > > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > > This patch is unifying the first 2 macro calls to make usage simpler, > > > and ease rte_trace adoption. > > > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > > it is creating global variable see, "int otx2_logtype_base; > > > > > > > > Note: the other usability weirdness is mandating declaring each trace > > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > > for rte_log too. I would like to NOT have trace to be the first > > > > library to explode > > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > > revisit later. > > > > > > You still did not give any argument against increasing the number > > > of constructors. > > > > If you are proposing the new scheme, you have to prove the overhead > > with a significant number of constructors > > and why it has differed from existing scheme of things. That's is the > > norm in opensource. > > I say there is no overhead. Please share the data. > The target is to simplify the usage and I prove it: > 1 call replacing 2 calls. That we can the same scheme with rte_log as well. > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 7:33 ` Jerin Jacob @ 2020-05-05 8:23 ` David Marchand 2020-05-05 10:12 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-05 8:23 UTC (permalink / raw) To: Jerin Jacob Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 9:33 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > What the proposed patch here. > > > # Making N constructors from one > > > # Grouping global variable and register function under a single Marco > > > and making it as N constructors. > > > Why can we do the same logic for rte_log? > > > > rte_log is simple, there is nothing to simplify. > > Why not make, rte_log_register() and the global variable under a macro? > That's something done by the proposed patch. At the moment, there is not much that would go into such a macro, but I had started to do some cleanups on logtype registration. I did not finish because the question of the default log level is still unclear (and I did not take the time). Having the logtype definition as part of the macro would be fine to me. https://patchwork.dpdk.org/patch/57743/ > > > > rte_trace requires 3 macros calls per trace type: > > > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > > > This patch is unifying the first 2 macro calls to make usage simpler, > > > > and ease rte_trace adoption. > > > > > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > > > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > > > it is creating global variable see, "int otx2_logtype_base; > > > > > > > > > > > Note: the other usability weirdness is mandating declaring each trace > > > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > > > for rte_log too. I would like to NOT have trace to be the first > > > > > library to explode > > > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > > > revisit later. > > > > > > > > You still did not give any argument against increasing the number > > > > of constructors. > > > > > > If you are proposing the new scheme, you have to prove the overhead > > > with a significant number of constructors > > > and why it has differed from existing scheme of things. That's is the > > > norm in opensource. > > > > I say there is no overhead. > > Please share the data. Measured time between first rte_trace_point_register and last one with a simple patch: diff --git a/lib/librte_eal/common/eal_common_trace.c b/lib/librte_eal/common/eal_common_trace.c index 875553d7e..95618314b 100644 --- a/lib/librte_eal/common/eal_common_trace.c +++ b/lib/librte_eal/common/eal_common_trace.c @@ -8,6 +8,7 @@ #include <regex.h> #include <rte_common.h> +#include <rte_cycles.h> #include <rte_errno.h> #include <rte_lcore.h> #include <rte_per_lcore.h> @@ -23,6 +24,9 @@ static RTE_DEFINE_PER_LCORE(int, ctf_count); static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); static struct trace trace = { .args = STAILQ_HEAD_INITIALIZER(trace.args), }; +uint64_t first_register; +uint64_t last_register; + struct trace * trace_obj_get(void) { @@ -43,6 +47,8 @@ eal_trace_init(void) /* Trace memory should start with 8B aligned for natural alignment */ RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) != 0); + trace_err("delta=%"PRIu64, last_register - first_register); + /* One of the trace point registration failed */ if (trace.register_errno) { rte_errno = trace.register_errno; @@ -425,6 +431,9 @@ __rte_trace_point_register(rte_trace_point_t *handle, const char *name, goto fail; } + if (first_register == 0) + first_register = rte_get_tsc_cycles(); + /* Check the size of the trace point object */ RTE_PER_LCORE(trace_point_sz) = 0; RTE_PER_LCORE(ctf_count) = 0; @@ -486,6 +495,8 @@ __rte_trace_point_register(rte_trace_point_t *handle, const char *name, STAILQ_INSERT_TAIL(&tp_list, tp, next); __atomic_thread_fence(__ATOMIC_RELEASE); + last_register = rte_get_tsc_cycles(); + /* All Good !!! */ return 0; free: I started testpmd 100 times for static and shared gcc builds (test-meson-builds.sh) on a system with a 2.6GHz xeon. v20.05-rc1-13-g08dd97130 (before patch): static: count=100, min=580812, max=1482326, avg=1764932 shared: count=100, min=554648, max=1344163, avg=1704638 v20.05-rc1-14-g44250f392 (after patch): static: count=100, min=668273, max=1530330, avg=1682548 shared: count=100, min=554634, max=1330264, avg=1672398 -- David Marchand ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 8:23 ` David Marchand @ 2020-05-05 10:12 ` Jerin Jacob 2020-05-05 10:26 ` Thomas Monjalon 2020-05-05 11:35 ` David Marchand 0 siblings, 2 replies; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 10:12 UTC (permalink / raw) To: David Marchand Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 1:53 PM David Marchand <david.marchand@redhat.com> wrote: > > On Tue, May 5, 2020 at 9:33 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > What the proposed patch here. > > > > # Making N constructors from one > > > > # Grouping global variable and register function under a single Marco > > > > and making it as N constructors. > > > > Why can we do the same logic for rte_log? > > > > > > rte_log is simple, there is nothing to simplify. > > > > Why not make, rte_log_register() and the global variable under a macro? > > That's something done by the proposed patch. > > At the moment, there is not much that would go into such a macro, but > I had started to do some cleanups on logtype registration. > I did not finish because the question of the default log level is > still unclear (and I did not take the time). > > Having the logtype definition as part of the macro would be fine to me. > https://patchwork.dpdk.org/patch/57743/ + Olivier (To get the feedback from rte_log PoV). The patchwork one is a bit different, IMO, Following is the mapping of this patch to rte_log one. Are we OK with the below semantics? 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 > > > > > > > rte_trace requires 3 macros calls per trace type: > > > > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > > > > This patch is unifying the first 2 macro calls to make usage simpler, > > > > > and ease rte_trace adoption. > > > > > > > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > > > > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > > > > it is creating global variable see, "int otx2_logtype_base; > > > > > > > > > > > > > > Note: the other usability weirdness is mandating declaring each trace > > > > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > > > > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > > > > for rte_log too. I would like to NOT have trace to be the first > > > > > > library to explode > > > > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > > > > revisit later. > > > > > > > > > > You still did not give any argument against increasing the number > > > > > of constructors. > > > > > > > > If you are proposing the new scheme, you have to prove the overhead > > > > with a significant number of constructors > > > > and why it has differed from existing scheme of things. That's is the > > > > norm in opensource. > > > > > > I say there is no overhead. > > > > Please share the data. > > Measured time between first rte_trace_point_register and last one with > a simple patch: I will try to reproduce this, once we finalize on the above synergy with rte_log. > > diff --git a/lib/librte_eal/common/eal_common_trace.c > b/lib/librte_eal/common/eal_common_trace.c > index 875553d7e..95618314b 100644 > --- a/lib/librte_eal/common/eal_common_trace.c > +++ b/lib/librte_eal/common/eal_common_trace.c > @@ -8,6 +8,7 @@ > #include <regex.h> > > #include <rte_common.h> > +#include <rte_cycles.h> > #include <rte_errno.h> > #include <rte_lcore.h> > #include <rte_per_lcore.h> > @@ -23,6 +24,9 @@ static RTE_DEFINE_PER_LCORE(int, ctf_count); > static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); > static struct trace trace = { .args = STAILQ_HEAD_INITIALIZER(trace.args), }; > > +uint64_t first_register; > +uint64_t last_register; > + > struct trace * > trace_obj_get(void) > { > @@ -43,6 +47,8 @@ eal_trace_init(void) > /* Trace memory should start with 8B aligned for natural alignment */ > RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) != 0); > > + trace_err("delta=%"PRIu64, last_register - first_register); > + > /* One of the trace point registration failed */ > if (trace.register_errno) { > rte_errno = trace.register_errno; > @@ -425,6 +431,9 @@ __rte_trace_point_register(rte_trace_point_t > *handle, const char *name, > goto fail; > } > > + if (first_register == 0) > + first_register = rte_get_tsc_cycles(); > + > /* Check the size of the trace point object */ > RTE_PER_LCORE(trace_point_sz) = 0; > RTE_PER_LCORE(ctf_count) = 0; > @@ -486,6 +495,8 @@ __rte_trace_point_register(rte_trace_point_t > *handle, const char *name, > STAILQ_INSERT_TAIL(&tp_list, tp, next); > __atomic_thread_fence(__ATOMIC_RELEASE); > > + last_register = rte_get_tsc_cycles(); > + > /* All Good !!! */ > return 0; > free: > > > I started testpmd 100 times for static and shared gcc builds > (test-meson-builds.sh) on a system with a 2.6GHz xeon. > > v20.05-rc1-13-g08dd97130 (before patch): > static: count=100, min=580812, max=1482326, avg=1764932 > shared: count=100, min=554648, max=1344163, avg=1704638 > > v20.05-rc1-14-g44250f392 (after patch): > static: count=100, min=668273, max=1530330, avg=1682548 > shared: count=100, min=554634, max=1330264, avg=1672398 > > > > -- > David Marchand > ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 10:12 ` Jerin Jacob @ 2020-05-05 10:26 ` Thomas Monjalon 2020-05-05 10:46 ` Jerin Jacob 2020-05-05 11:35 ` David Marchand 1 sibling, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-05 10:26 UTC (permalink / raw) To: David Marchand, Jerin Jacob Cc: dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 05/05/2020 12:12, Jerin Jacob: > On Tue, May 5, 2020 at 1:53 PM David Marchand <david.marchand@redhat.com> wrote: > > On Tue, May 5, 2020 at 9:33 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > What the proposed patch here. > > > > > # Making N constructors from one > > > > > # Grouping global variable and register function under a single Marco > > > > > and making it as N constructors. > > > > > Why can we do the same logic for rte_log? > > > > > > > > rte_log is simple, there is nothing to simplify. > > > > > > Why not make, rte_log_register() and the global variable under a macro? > > > That's something done by the proposed patch. > > > > At the moment, there is not much that would go into such a macro, but > > I had started to do some cleanups on logtype registration. > > I did not finish because the question of the default log level is > > still unclear (and I did not take the time). > > > > Having the logtype definition as part of the macro would be fine to me. > > https://patchwork.dpdk.org/patch/57743/ > > + Olivier (To get the feedback from rte_log PoV). > > The patchwork one is a bit different, IMO, Following is the mapping of > this patch to rte_log one. > > Are we OK with the below semantics? > > > 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); \ > +} > + Yes I agree, we could do that. And now I better understand what you mean comparing rte_trace and rte_log. > > > > > > rte_trace requires 3 macros calls per trace type: > > > > > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > > > > > This patch is unifying the first 2 macro calls to make usage simpler, > > > > > > and ease rte_trace adoption. > > > > > > > > > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > > > > > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > > > > > it is creating global variable see, "int otx2_logtype_base; > > > > > > > > > > > > > > > > > Note: the other usability weirdness is mandating declaring each trace > > > > > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > > > > > > > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > > > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > > > > > for rte_log too. I would like to NOT have trace to be the first > > > > > > > library to explode > > > > > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > > > > > revisit later. > > > > > > > > > > > > You still did not give any argument against increasing the number > > > > > > of constructors. > > > > > > > > > > If you are proposing the new scheme, you have to prove the overhead > > > > > with a significant number of constructors > > > > > and why it has differed from existing scheme of things. That's is the > > > > > norm in opensource. > > > > > > > > I say there is no overhead. > > > > > > Please share the data. > > > > Measured time between first rte_trace_point_register and last one with > > a simple patch: > > I will try to reproduce this, once we finalize on the above synergy > with rte_log. > > > > > > diff --git a/lib/librte_eal/common/eal_common_trace.c > > b/lib/librte_eal/common/eal_common_trace.c > > index 875553d7e..95618314b 100644 > > --- a/lib/librte_eal/common/eal_common_trace.c > > +++ b/lib/librte_eal/common/eal_common_trace.c > > @@ -8,6 +8,7 @@ > > #include <regex.h> > > > > #include <rte_common.h> > > +#include <rte_cycles.h> > > #include <rte_errno.h> > > #include <rte_lcore.h> > > #include <rte_per_lcore.h> > > @@ -23,6 +24,9 @@ static RTE_DEFINE_PER_LCORE(int, ctf_count); > > static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); > > static struct trace trace = { .args = STAILQ_HEAD_INITIALIZER(trace.args), }; > > > > +uint64_t first_register; > > +uint64_t last_register; > > + > > struct trace * > > trace_obj_get(void) > > { > > @@ -43,6 +47,8 @@ eal_trace_init(void) > > /* Trace memory should start with 8B aligned for natural alignment */ > > RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) != 0); > > > > + trace_err("delta=%"PRIu64, last_register - first_register); > > + > > /* One of the trace point registration failed */ > > if (trace.register_errno) { > > rte_errno = trace.register_errno; > > @@ -425,6 +431,9 @@ __rte_trace_point_register(rte_trace_point_t > > *handle, const char *name, > > goto fail; > > } > > > > + if (first_register == 0) > > + first_register = rte_get_tsc_cycles(); > > + > > /* Check the size of the trace point object */ > > RTE_PER_LCORE(trace_point_sz) = 0; > > RTE_PER_LCORE(ctf_count) = 0; > > @@ -486,6 +495,8 @@ __rte_trace_point_register(rte_trace_point_t > > *handle, const char *name, > > STAILQ_INSERT_TAIL(&tp_list, tp, next); > > __atomic_thread_fence(__ATOMIC_RELEASE); > > > > + last_register = rte_get_tsc_cycles(); > > + > > /* All Good !!! */ > > return 0; > > free: > > > > > > I started testpmd 100 times for static and shared gcc builds > > (test-meson-builds.sh) on a system with a 2.6GHz xeon. > > > > v20.05-rc1-13-g08dd97130 (before patch): > > static: count=100, min=580812, max=1482326, avg=1764932 > > shared: count=100, min=554648, max=1344163, avg=1704638 > > > > v20.05-rc1-14-g44250f392 (after patch): > > static: count=100, min=668273, max=1530330, avg=1682548 > > shared: count=100, min=554634, max=1330264, avg=1672398 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 10:26 ` Thomas Monjalon @ 2020-05-05 10:46 ` Jerin Jacob 2020-05-05 11:48 ` Olivier Matz 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 10:46 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 3:56 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 12:12, Jerin Jacob: > > On Tue, May 5, 2020 at 1:53 PM David Marchand <david.marchand@redhat.com> wrote: > > > On Tue, May 5, 2020 at 9:33 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > What the proposed patch here. > > > > > > # Making N constructors from one > > > > > > # Grouping global variable and register function under a single Marco > > > > > > and making it as N constructors. > > > > > > Why can we do the same logic for rte_log? > > > > > > > > > > rte_log is simple, there is nothing to simplify. > > > > > > > > Why not make, rte_log_register() and the global variable under a macro? > > > > That's something done by the proposed patch. > > > > > > At the moment, there is not much that would go into such a macro, but > > > I had started to do some cleanups on logtype registration. > > > I did not finish because the question of the default log level is > > > still unclear (and I did not take the time). > > > > > > Having the logtype definition as part of the macro would be fine to me. > > > https://patchwork.dpdk.org/patch/57743/ > > > > + Olivier (To get the feedback from rte_log PoV). > > > > The patchwork one is a bit different, IMO, Following is the mapping of > > this patch to rte_log one. > > > > Are we OK with the below semantics? > > > > > > 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); \ > > +} > > + > > > Yes I agree, we could do that. > And now I better understand what you mean comparing rte_trace and rte_log. OK. Let Olivier share his view, I was/is under the impression that, The reason for not have this silly Marco to don't explode constructor usage in dpdk If we are OK this scheme then lets first clean up rte_log registration. > > > > > > > > > > rte_trace requires 3 macros calls per trace type: > > > > > > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > > > > > > This patch is unifying the first 2 macro calls to make usage simpler, > > > > > > > and ease rte_trace adoption. > > > > > > > > > > > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > > > > > > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > > > > > > it is creating global variable see, "int otx2_logtype_base; > > > > > > > > > > > > > > > > > > > > Note: the other usability weirdness is mandating declaring each trace > > > > > > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > > > > > > > > > > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > > > > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > > > > > > for rte_log too. I would like to NOT have trace to be the first > > > > > > > > library to explode > > > > > > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > > > > > > revisit later. > > > > > > > > > > > > > > You still did not give any argument against increasing the number > > > > > > > of constructors. > > > > > > > > > > > > If you are proposing the new scheme, you have to prove the overhead > > > > > > with a significant number of constructors > > > > > > and why it has differed from existing scheme of things. That's is the > > > > > > norm in opensource. > > > > > > > > > > I say there is no overhead. > > > > > > > > Please share the data. > > > > > > Measured time between first rte_trace_point_register and last one with > > > a simple patch: > > > > I will try to reproduce this, once we finalize on the above synergy > > with rte_log. > > > > > > > > > > diff --git a/lib/librte_eal/common/eal_common_trace.c > > > b/lib/librte_eal/common/eal_common_trace.c > > > index 875553d7e..95618314b 100644 > > > --- a/lib/librte_eal/common/eal_common_trace.c > > > +++ b/lib/librte_eal/common/eal_common_trace.c > > > @@ -8,6 +8,7 @@ > > > #include <regex.h> > > > > > > #include <rte_common.h> > > > +#include <rte_cycles.h> > > > #include <rte_errno.h> > > > #include <rte_lcore.h> > > > #include <rte_per_lcore.h> > > > @@ -23,6 +24,9 @@ static RTE_DEFINE_PER_LCORE(int, ctf_count); > > > static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); > > > static struct trace trace = { .args = STAILQ_HEAD_INITIALIZER(trace.args), }; > > > > > > +uint64_t first_register; > > > +uint64_t last_register; > > > + > > > struct trace * > > > trace_obj_get(void) > > > { > > > @@ -43,6 +47,8 @@ eal_trace_init(void) > > > /* Trace memory should start with 8B aligned for natural alignment */ > > > RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) != 0); > > > > > > + trace_err("delta=%"PRIu64, last_register - first_register); > > > + > > > /* One of the trace point registration failed */ > > > if (trace.register_errno) { > > > rte_errno = trace.register_errno; > > > @@ -425,6 +431,9 @@ __rte_trace_point_register(rte_trace_point_t > > > *handle, const char *name, > > > goto fail; > > > } > > > > > > + if (first_register == 0) > > > + first_register = rte_get_tsc_cycles(); > > > + > > > /* Check the size of the trace point object */ > > > RTE_PER_LCORE(trace_point_sz) = 0; > > > RTE_PER_LCORE(ctf_count) = 0; > > > @@ -486,6 +495,8 @@ __rte_trace_point_register(rte_trace_point_t > > > *handle, const char *name, > > > STAILQ_INSERT_TAIL(&tp_list, tp, next); > > > __atomic_thread_fence(__ATOMIC_RELEASE); > > > > > > + last_register = rte_get_tsc_cycles(); > > > + > > > /* All Good !!! */ > > > return 0; > > > free: > > > > > > > > > I started testpmd 100 times for static and shared gcc builds > > > (test-meson-builds.sh) on a system with a 2.6GHz xeon. > > > > > > v20.05-rc1-13-g08dd97130 (before patch): > > > static: count=100, min=580812, max=1482326, avg=1764932 > > > shared: count=100, min=554648, max=1344163, avg=1704638 > > > > > > v20.05-rc1-14-g44250f392 (after patch): > > > static: count=100, min=668273, max=1530330, avg=1682548 > > > shared: count=100, min=554634, max=1330264, avg=1672398 > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 10:46 ` Jerin Jacob @ 2020-05-05 11:48 ` Olivier Matz 0 siblings, 0 replies; 55+ messages in thread From: Olivier Matz @ 2020-05-05 11:48 UTC (permalink / raw) To: Jerin Jacob Cc: Thomas Monjalon, David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko Hi, On Tue, May 05, 2020 at 04:16:02PM +0530, Jerin Jacob wrote: > On Tue, May 5, 2020 at 3:56 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > 05/05/2020 12:12, Jerin Jacob: > > > On Tue, May 5, 2020 at 1:53 PM David Marchand <david.marchand@redhat.com> wrote: > > > > On Tue, May 5, 2020 at 9:33 AM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > What the proposed patch here. > > > > > > > # Making N constructors from one > > > > > > > # Grouping global variable and register function under a single Marco > > > > > > > and making it as N constructors. > > > > > > > Why can we do the same logic for rte_log? > > > > > > > > > > > > rte_log is simple, there is nothing to simplify. > > > > > > > > > > Why not make, rte_log_register() and the global variable under a macro? > > > > > That's something done by the proposed patch. > > > > > > > > At the moment, there is not much that would go into such a macro, but > > > > I had started to do some cleanups on logtype registration. > > > > I did not finish because the question of the default log level is > > > > still unclear (and I did not take the time). > > > > > > > > Having the logtype definition as part of the macro would be fine to me. > > > > https://patchwork.dpdk.org/patch/57743/ > > > > > > + Olivier (To get the feedback from rte_log PoV). > > > > > > The patchwork one is a bit different, IMO, Following is the mapping of > > > this patch to rte_log one. > > > > > > Are we OK with the below semantics? > > > > > > > > > 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); \ > > > +} > > > + > > > > > > Yes I agree, we could do that. > > And now I better understand what you mean comparing rte_trace and rte_log. > > OK. > > Let Olivier share his view, I was/is under the impression that, The > reason for not have this silly Marco to > don't explode constructor usage in dpdk > > If we are OK this scheme then lets first clean up rte_log registration. Honnestly, I had no particular idea in mind about constructor number when I added the rte_log_register() API. To me, it was quite simple: just call a register function when you need a new log type. Now, as it's mostly (always?) done at init time, I'm fine with the the principle of having a macro to register new logs, given we also keep the previous API. To get back on the topic of the thread (RTE_TRACE), I think a simpler API (one macro) is better. Since it's a new API, it makes sense to make it as good as possible for the first version. And by the way, thank you for this nice work. Regards, Olivier > > > > > > > > > > > > > > > > rte_trace requires 3 macros calls per trace type: > > > > > > > > RTE_TRACE_POINT_REGISTER, RTE_TRACE_POINT_DEFINE, RTE_TRACE_POINT_ARGS > > > > > > > > This patch is unifying the first 2 macro calls to make usage simpler, > > > > > > > > and ease rte_trace adoption. > > > > > > > > > > > > > > RTE_TRACE_POINT_ARGS is NOP and for the syntax. > > > > > > > It is similar to rte_log. rte_log don't have RTE_TRACE_POINT_REGISTER instead > > > > > > > it is creating global variable see, "int otx2_logtype_base; > > > > > > > > > > > > > > > > > > > > > > > Note: the other usability weirdness is mandating declaring each trace > > > > > > > > function with a magic double underscore prefix which appears nowhere else. > > > > > > > > > > > > > > > > > > > > > > > > > Analyze the impact wrt boot time and cross-platform pov as the log > > > > > > > > > has a lot of entries to test. If the usage makes sense then it should make sense > > > > > > > > > for rte_log too. I would like to NOT have trace to be the first > > > > > > > > > library to explode > > > > > > > > > with the constructor scheme. I suggest removing this specific patch from RC2 and > > > > > > > > > revisit later. > > > > > > > > > > > > > > > > You still did not give any argument against increasing the number > > > > > > > > of constructors. > > > > > > > > > > > > > > If you are proposing the new scheme, you have to prove the overhead > > > > > > > with a significant number of constructors > > > > > > > and why it has differed from existing scheme of things. That's is the > > > > > > > norm in opensource. > > > > > > > > > > > > I say there is no overhead. > > > > > > > > > > Please share the data. > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > a simple patch: > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > with rte_log. > > > > > > > > > > > > > > diff --git a/lib/librte_eal/common/eal_common_trace.c > > > > b/lib/librte_eal/common/eal_common_trace.c > > > > index 875553d7e..95618314b 100644 > > > > --- a/lib/librte_eal/common/eal_common_trace.c > > > > +++ b/lib/librte_eal/common/eal_common_trace.c > > > > @@ -8,6 +8,7 @@ > > > > #include <regex.h> > > > > > > > > #include <rte_common.h> > > > > +#include <rte_cycles.h> > > > > #include <rte_errno.h> > > > > #include <rte_lcore.h> > > > > #include <rte_per_lcore.h> > > > > @@ -23,6 +24,9 @@ static RTE_DEFINE_PER_LCORE(int, ctf_count); > > > > static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); > > > > static struct trace trace = { .args = STAILQ_HEAD_INITIALIZER(trace.args), }; > > > > > > > > +uint64_t first_register; > > > > +uint64_t last_register; > > > > + > > > > struct trace * > > > > trace_obj_get(void) > > > > { > > > > @@ -43,6 +47,8 @@ eal_trace_init(void) > > > > /* Trace memory should start with 8B aligned for natural alignment */ > > > > RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) != 0); > > > > > > > > + trace_err("delta=%"PRIu64, last_register - first_register); > > > > + > > > > /* One of the trace point registration failed */ > > > > if (trace.register_errno) { > > > > rte_errno = trace.register_errno; > > > > @@ -425,6 +431,9 @@ __rte_trace_point_register(rte_trace_point_t > > > > *handle, const char *name, > > > > goto fail; > > > > } > > > > > > > > + if (first_register == 0) > > > > + first_register = rte_get_tsc_cycles(); > > > > + > > > > /* Check the size of the trace point object */ > > > > RTE_PER_LCORE(trace_point_sz) = 0; > > > > RTE_PER_LCORE(ctf_count) = 0; > > > > @@ -486,6 +495,8 @@ __rte_trace_point_register(rte_trace_point_t > > > > *handle, const char *name, > > > > STAILQ_INSERT_TAIL(&tp_list, tp, next); > > > > __atomic_thread_fence(__ATOMIC_RELEASE); > > > > > > > > + last_register = rte_get_tsc_cycles(); > > > > + > > > > /* All Good !!! */ > > > > return 0; > > > > free: > > > > > > > > > > > > I started testpmd 100 times for static and shared gcc builds > > > > (test-meson-builds.sh) on a system with a 2.6GHz xeon. > > > > > > > > v20.05-rc1-13-g08dd97130 (before patch): > > > > static: count=100, min=580812, max=1482326, avg=1764932 > > > > shared: count=100, min=554648, max=1344163, avg=1704638 > > > > > > > > v20.05-rc1-14-g44250f392 (after patch): > > > > static: count=100, min=668273, max=1530330, avg=1682548 > > > > shared: count=100, min=554634, max=1330264, avg=1672398 > > > > > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 10:12 ` Jerin Jacob 2020-05-05 10:26 ` Thomas Monjalon @ 2020-05-05 11:35 ` David Marchand 2020-05-05 12:26 ` Jerin Jacob 1 sibling, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-05 11:35 UTC (permalink / raw) To: Jerin Jacob Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > Please share the data. > > > > Measured time between first rte_trace_point_register and last one with > > a simple patch: > > I will try to reproduce this, once we finalize on the above synergy > with rte_log. I took the time to provide measure but you won't take the time to look at this. Really nice. -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 11:35 ` David Marchand @ 2020-05-05 12:26 ` Jerin Jacob 2020-05-05 15:25 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 12:26 UTC (permalink / raw) To: David Marchand Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > Please share the data. > > > > > > Measured time between first rte_trace_point_register and last one with > > > a simple patch: > > > > I will try to reproduce this, once we finalize on the above synergy > > with rte_log. > > I took the time to provide measure but you won't take the time to look at this. I will spend time on this. I would like to test with a shared library also and more tracepoints. I was looking for an agreement on using the constructor for rte_log as well(Just make sure the direction is correct). Next steps: - I will analyze the come back on this overhead on this thread. - Olivier is OK for changing the RTE_LOG_REGSISTER macro, So we could clean the log as well. > Really nice. > > > -- > David Marchand > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 12:26 ` Jerin Jacob @ 2020-05-05 15:25 ` Jerin Jacob 2020-05-05 16:28 ` David Marchand 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 15:25 UTC (permalink / raw) To: David Marchand Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > Please share the data. > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > a simple patch: > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > with rte_log. > > > > I took the time to provide measure but you won't take the time to look at this. > > I will spend time on this. I would like to test with a shared library > also and more tracepoints. > I was looking for an agreement on using the constructor for rte_log as > well(Just make sure the direction is correct). > > Next steps: > - I will analyze the come back on this overhead on this thread. I have added 500 constructors for testing the overhead with the shared build and static build. My results inline with your results aka negligible overhead. David, Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? I would like to have rte_log and rte_trace semantics similar to registration. If you are not planning to submit the rte_log patch then I can send one for RC2 cleanup. > - Olivier is OK for changing the RTE_LOG_REGSISTER macro, So we could > clean the log as well. > > > > Really nice. > > > > > > > > > -- > > David Marchand > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 15:25 ` Jerin Jacob @ 2020-05-05 16:28 ` David Marchand 2020-05-05 16:46 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-05 16:28 UTC (permalink / raw) To: Jerin Jacob Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > Please share the data. > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > a simple patch: > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > with rte_log. > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > I will spend time on this. I would like to test with a shared library > > also and more tracepoints. > > I was looking for an agreement on using the constructor for rte_log as > > well(Just make sure the direction is correct). > > > > Next steps: > > - I will analyze the come back on this overhead on this thread. > > I have added 500 constructors for testing the overhead with the shared > build and static build. > My results inline with your results aka negligible overhead. > > David, > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > I would like to have rte_log and rte_trace semantics similar to registration. > If you are not planning to submit the rte_log patch then I can send > one for RC2 cleanup. It won't be possible for me. Relying on the current rte_log_register is buggy with shared builds, as drivers are calling rte_log_register, then impose a default level without caring about what the user passed. So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. What I wanted to do: - merge rte_log_register_and_pick_level() (experimental) into rte_log_register, doing this should be fine from my pov, - reconsider the relevance of a fallback logtype when registration fails, - shoot the default level per component thing: levels meaning is fragmented across the drivers/libraries because of it, but this will open a big box of stuff, -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 16:28 ` David Marchand @ 2020-05-05 16:46 ` Jerin Jacob 2020-05-05 16:58 ` Thomas Monjalon 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 16:46 UTC (permalink / raw) To: David Marchand Cc: Thomas Monjalon, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > Please share the data. > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > a simple patch: > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > with rte_log. > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > I will spend time on this. I would like to test with a shared library > > > also and more tracepoints. > > > I was looking for an agreement on using the constructor for rte_log as > > > well(Just make sure the direction is correct). > > > > > > Next steps: > > > - I will analyze the come back on this overhead on this thread. > > > > I have added 500 constructors for testing the overhead with the shared > > build and static build. > > My results inline with your results aka negligible overhead. > > > > David, > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > I would like to have rte_log and rte_trace semantics similar to registration. > > If you are not planning to submit the rte_log patch then I can send > > one for RC2 cleanup. > > It won't be possible for me. I can do that if we agree on the specifics. > > Relying on the current rte_log_register is buggy with shared builds, > as drivers are calling rte_log_register, then impose a default level > without caring about what the user passed. > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > What I wanted to do: > - merge rte_log_register_and_pick_level() (experimental) into > rte_log_register, doing this should be fine from my pov, > - reconsider the relevance of a fallback logtype when registration fails, > - shoot the default level per component thing: levels meaning is > fragmented across the drivers/libraries because of it, but this will > open a big box of stuff, This you are referring to internal implementation improvement. Right? I was referring to remove the current clutter[1] If we stick the following as the interface. Then you can do other improvements when you get time that won't change the consumer code or interference part. #define RTE_LOG_REGISTER(type, name, level) [1] > > -/** > > - * @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); \ > > +} > > + > > > > > -- > David Marchand > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 16:46 ` Jerin Jacob @ 2020-05-05 16:58 ` Thomas Monjalon 2020-05-05 17:08 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-05 16:58 UTC (permalink / raw) To: David Marchand, Jerin Jacob Cc: dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 05/05/2020 18:46, Jerin Jacob: > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > Please share the data. > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > a simple patch: > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > with rte_log. > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > also and more tracepoints. > > > > I was looking for an agreement on using the constructor for rte_log as > > > > well(Just make sure the direction is correct). > > > > > > > > Next steps: > > > > - I will analyze the come back on this overhead on this thread. > > > > > > I have added 500 constructors for testing the overhead with the shared > > > build and static build. > > > My results inline with your results aka negligible overhead. > > > > > > David, > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > If you are not planning to submit the rte_log patch then I can send > > > one for RC2 cleanup. > > > > It won't be possible for me. > > I can do that if we agree on the specifics. > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > as drivers are calling rte_log_register, then impose a default level > > without caring about what the user passed. > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > What I wanted to do: > > - merge rte_log_register_and_pick_level() (experimental) into > > rte_log_register, doing this should be fine from my pov, > > - reconsider the relevance of a fallback logtype when registration fails, > > - shoot the default level per component thing: levels meaning is > > fragmented across the drivers/libraries because of it, but this will > > open a big box of stuff, > > This you are referring to internal implementation improvement. Right? > I was referring to remove the current clutter[1] > If we stick the following as the interface. Then you can do other > improvements when you get time > that won't change the consumer code or interference part. > > #define RTE_LOG_REGISTER(type, name, level) This discussion is interesting but out of scope for rte_trace. I am also interested in rte_log registration cleanup, but I know it is too much work for the last weeks of 20.05. As Olivier said about rte_trace, "Since it's a new API, it makes sense to make it as good as possible for the first version." So please let's conclude on this rte_trace patch for 20.05-rc2, and commit to fix rte_log registration in the first days of 20.08. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 16:58 ` Thomas Monjalon @ 2020-05-05 17:08 ` Jerin Jacob 2020-05-05 17:09 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 17:08 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 18:46, Jerin Jacob: > > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > a simple patch: > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > with rte_log. > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > also and more tracepoints. > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > well(Just make sure the direction is correct). > > > > > > > > > > Next steps: > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > build and static build. > > > > My results inline with your results aka negligible overhead. > > > > > > > > David, > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > If you are not planning to submit the rte_log patch then I can send > > > > one for RC2 cleanup. > > > > > > It won't be possible for me. > > > > I can do that if we agree on the specifics. > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > as drivers are calling rte_log_register, then impose a default level > > > without caring about what the user passed. > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > What I wanted to do: > > > - merge rte_log_register_and_pick_level() (experimental) into > > > rte_log_register, doing this should be fine from my pov, > > > - reconsider the relevance of a fallback logtype when registration fails, > > > - shoot the default level per component thing: levels meaning is > > > fragmented across the drivers/libraries because of it, but this will > > > open a big box of stuff, > > > > This you are referring to internal implementation improvement. Right? > > I was referring to remove the current clutter[1] > > If we stick the following as the interface. Then you can do other > > improvements when you get time > > that won't change the consumer code or interference part. > > > > #define RTE_LOG_REGISTER(type, name, level) > > This discussion is interesting but out of scope for rte_trace. > I am also interested in rte_log registration cleanup, > but I know it is too much work for the last weeks of 20.05. > > As Olivier said about rte_trace, > "Since it's a new API, it makes sense to make > it as good as possible for the first version." > > So please let's conclude on this rte_trace patch for 20.05-rc2, > and commit to fix rte_log registration in the first days of 20.08. Why not hold the trace registration patch 2/8 and apply rest for RC2. Once we have synergy between the registration scheme between rte_log and rte_trace apply the patch for RC2. > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 17:08 ` Jerin Jacob @ 2020-05-05 17:09 ` Jerin Jacob 2020-05-05 17:20 ` Thomas Monjalon 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 17:09 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 10:38 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > 05/05/2020 18:46, Jerin Jacob: > > > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > > a simple patch: > > > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > > with rte_log. > > > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > > also and more tracepoints. > > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > > well(Just make sure the direction is correct). > > > > > > > > > > > > Next steps: > > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > > build and static build. > > > > > My results inline with your results aka negligible overhead. > > > > > > > > > > David, > > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > > If you are not planning to submit the rte_log patch then I can send > > > > > one for RC2 cleanup. > > > > > > > > It won't be possible for me. > > > > > > I can do that if we agree on the specifics. > > > > > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > > as drivers are calling rte_log_register, then impose a default level > > > > without caring about what the user passed. > > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > > > What I wanted to do: > > > > - merge rte_log_register_and_pick_level() (experimental) into > > > > rte_log_register, doing this should be fine from my pov, > > > > - reconsider the relevance of a fallback logtype when registration fails, > > > > - shoot the default level per component thing: levels meaning is > > > > fragmented across the drivers/libraries because of it, but this will > > > > open a big box of stuff, > > > > > > This you are referring to internal implementation improvement. Right? > > > I was referring to remove the current clutter[1] > > > If we stick the following as the interface. Then you can do other > > > improvements when you get time > > > that won't change the consumer code or interference part. > > > > > > #define RTE_LOG_REGISTER(type, name, level) > > > > This discussion is interesting but out of scope for rte_trace. > > I am also interested in rte_log registration cleanup, > > but I know it is too much work for the last weeks of 20.05. > > > > As Olivier said about rte_trace, > > "Since it's a new API, it makes sense to make > > it as good as possible for the first version." > > > > So please let's conclude on this rte_trace patch for 20.05-rc2, > > and commit to fix rte_log registration in the first days of 20.08. > > Why not hold the trace registration patch 2/8 and apply rest for RC2. > Once we have synergy between the registration scheme between rte_log > and rte_trace > apply the patch for RC2. I meant, Once we have synergy between the registration scheme between rte_log and rte_trace apply the patch for _20.08_? > > > > > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 17:09 ` Jerin Jacob @ 2020-05-05 17:20 ` Thomas Monjalon 2020-05-05 17:28 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-05 17:20 UTC (permalink / raw) To: Jerin Jacob Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 05/05/2020 19:09, Jerin Jacob: > On Tue, May 5, 2020 at 10:38 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > 05/05/2020 18:46, Jerin Jacob: > > > > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > > > a simple patch: > > > > > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > > > with rte_log. > > > > > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > > > also and more tracepoints. > > > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > > > well(Just make sure the direction is correct). > > > > > > > > > > > > > > Next steps: > > > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > > > build and static build. > > > > > > My results inline with your results aka negligible overhead. > > > > > > > > > > > > David, > > > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > > > If you are not planning to submit the rte_log patch then I can send > > > > > > one for RC2 cleanup. > > > > > > > > > > It won't be possible for me. > > > > > > > > I can do that if we agree on the specifics. > > > > > > > > > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > > > as drivers are calling rte_log_register, then impose a default level > > > > > without caring about what the user passed. > > > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > > > > > What I wanted to do: > > > > > - merge rte_log_register_and_pick_level() (experimental) into > > > > > rte_log_register, doing this should be fine from my pov, > > > > > - reconsider the relevance of a fallback logtype when registration fails, > > > > > - shoot the default level per component thing: levels meaning is > > > > > fragmented across the drivers/libraries because of it, but this will > > > > > open a big box of stuff, > > > > > > > > This you are referring to internal implementation improvement. Right? > > > > I was referring to remove the current clutter[1] > > > > If we stick the following as the interface. Then you can do other > > > > improvements when you get time > > > > that won't change the consumer code or interference part. > > > > > > > > #define RTE_LOG_REGISTER(type, name, level) > > > > > > This discussion is interesting but out of scope for rte_trace. > > > I am also interested in rte_log registration cleanup, > > > but I know it is too much work for the last weeks of 20.05. > > > > > > As Olivier said about rte_trace, > > > "Since it's a new API, it makes sense to make > > > it as good as possible for the first version." > > > > > > So please let's conclude on this rte_trace patch for 20.05-rc2, > > > and commit to fix rte_log registration in the first days of 20.08. > > > > Why not hold the trace registration patch 2/8 and apply rest for RC2. > > Once we have synergy between the registration scheme between rte_log > > and rte_trace > > apply the patch for RC2. > > I meant, Once we have synergy between the registration scheme between > rte_log and rte_trace > apply the patch for _20.08_? Because of what I wrote above: As Olivier said about rte_trace, "Since it's a new API, it makes sense to make it as good as possible for the first version." The intent is to show an API as simple as possible in order to have a maximum of developers integrating it, and getting more interesting feedbacks. In other words, we want to make your work shine for prime time. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 17:20 ` Thomas Monjalon @ 2020-05-05 17:28 ` Jerin Jacob 2020-05-05 20:10 ` Thomas Monjalon 0 siblings, 1 reply; 55+ messages in thread From: Jerin Jacob @ 2020-05-05 17:28 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Tue, May 5, 2020 at 10:50 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 19:09, Jerin Jacob: > > On Tue, May 5, 2020 at 10:38 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > 05/05/2020 18:46, Jerin Jacob: > > > > > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > > > > a simple patch: > > > > > > > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > > > > with rte_log. > > > > > > > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > > > > also and more tracepoints. > > > > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > > > > well(Just make sure the direction is correct). > > > > > > > > > > > > > > > > Next steps: > > > > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > > > > build and static build. > > > > > > > My results inline with your results aka negligible overhead. > > > > > > > > > > > > > > David, > > > > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > > > > If you are not planning to submit the rte_log patch then I can send > > > > > > > one for RC2 cleanup. > > > > > > > > > > > > It won't be possible for me. > > > > > > > > > > I can do that if we agree on the specifics. > > > > > > > > > > > > > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > > > > as drivers are calling rte_log_register, then impose a default level > > > > > > without caring about what the user passed. > > > > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > > > > > > > What I wanted to do: > > > > > > - merge rte_log_register_and_pick_level() (experimental) into > > > > > > rte_log_register, doing this should be fine from my pov, > > > > > > - reconsider the relevance of a fallback logtype when registration fails, > > > > > > - shoot the default level per component thing: levels meaning is > > > > > > fragmented across the drivers/libraries because of it, but this will > > > > > > open a big box of stuff, > > > > > > > > > > This you are referring to internal implementation improvement. Right? > > > > > I was referring to remove the current clutter[1] > > > > > If we stick the following as the interface. Then you can do other > > > > > improvements when you get time > > > > > that won't change the consumer code or interference part. > > > > > > > > > > #define RTE_LOG_REGISTER(type, name, level) > > > > > > > > This discussion is interesting but out of scope for rte_trace. > > > > I am also interested in rte_log registration cleanup, > > > > but I know it is too much work for the last weeks of 20.05. > > > > > > > > As Olivier said about rte_trace, > > > > "Since it's a new API, it makes sense to make > > > > it as good as possible for the first version." > > > > > > > > So please let's conclude on this rte_trace patch for 20.05-rc2, > > > > and commit to fix rte_log registration in the first days of 20.08. > > > > > > Why not hold the trace registration patch 2/8 and apply rest for RC2. > > > Once we have synergy between the registration scheme between rte_log > > > and rte_trace > > > apply the patch for RC2. > > > > I meant, Once we have synergy between the registration scheme between > > rte_log and rte_trace > > apply the patch for _20.08_? > > Because of what I wrote above: > As Olivier said about rte_trace, > "Since it's a new API, it makes sense to make > it as good as possible for the first version." > > The intent is to show an API as simple as possible > in order to have a maximum of developers integrating it, > and getting more interesting feedbacks. > > In other words, we want to make your work shine for prime time. I like that, If it is not shining just because of 2/8 not applying now then I fine with that. Anyway, it is an experimental API, There is still room to change and nothing is set and stone. For me, the synergy between log/trace interface important as trace needs to replace rte_log. > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 17:28 ` Jerin Jacob @ 2020-05-05 20:10 ` Thomas Monjalon 2020-05-06 6:11 ` Jerin Jacob 0 siblings, 1 reply; 55+ messages in thread From: Thomas Monjalon @ 2020-05-05 20:10 UTC (permalink / raw) To: Jerin Jacob Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 05/05/2020 19:28, Jerin Jacob: > On Tue, May 5, 2020 at 10:50 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 19:09, Jerin Jacob: > > > On Tue, May 5, 2020 at 10:38 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > > 05/05/2020 18:46, Jerin Jacob: > > > > > > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > > > > > a simple patch: > > > > > > > > > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > > > > > with rte_log. > > > > > > > > > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > > > > > also and more tracepoints. > > > > > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > > > > > well(Just make sure the direction is correct). > > > > > > > > > > > > > > > > > > Next steps: > > > > > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > > > > > build and static build. > > > > > > > > My results inline with your results aka negligible overhead. > > > > > > > > > > > > > > > > David, > > > > > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > > > > > If you are not planning to submit the rte_log patch then I can send > > > > > > > > one for RC2 cleanup. > > > > > > > > > > > > > > It won't be possible for me. > > > > > > > > > > > > I can do that if we agree on the specifics. > > > > > > > > > > > > > > > > > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > > > > > as drivers are calling rte_log_register, then impose a default level > > > > > > > without caring about what the user passed. > > > > > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > > > > > > > > > What I wanted to do: > > > > > > > - merge rte_log_register_and_pick_level() (experimental) into > > > > > > > rte_log_register, doing this should be fine from my pov, > > > > > > > - reconsider the relevance of a fallback logtype when registration fails, > > > > > > > - shoot the default level per component thing: levels meaning is > > > > > > > fragmented across the drivers/libraries because of it, but this will > > > > > > > open a big box of stuff, > > > > > > > > > > > > This you are referring to internal implementation improvement. Right? > > > > > > I was referring to remove the current clutter[1] > > > > > > If we stick the following as the interface. Then you can do other > > > > > > improvements when you get time > > > > > > that won't change the consumer code or interference part. > > > > > > > > > > > > #define RTE_LOG_REGISTER(type, name, level) > > > > > > > > > > This discussion is interesting but out of scope for rte_trace. > > > > > I am also interested in rte_log registration cleanup, > > > > > but I know it is too much work for the last weeks of 20.05. > > > > > > > > > > As Olivier said about rte_trace, > > > > > "Since it's a new API, it makes sense to make > > > > > it as good as possible for the first version." > > > > > > > > > > So please let's conclude on this rte_trace patch for 20.05-rc2, > > > > > and commit to fix rte_log registration in the first days of 20.08. > > > > > > > > Why not hold the trace registration patch 2/8 and apply rest for RC2. > > > > Once we have synergy between the registration scheme between rte_log > > > > and rte_trace > > > > apply the patch for RC2. > > > > > > I meant, Once we have synergy between the registration scheme between > > > rte_log and rte_trace > > > apply the patch for _20.08_? > > > > Because of what I wrote above: > > As Olivier said about rte_trace, > > "Since it's a new API, it makes sense to make > > it as good as possible for the first version." > > > > The intent is to show an API as simple as possible > > in order to have a maximum of developers integrating it, > > and getting more interesting feedbacks. > > > > In other words, we want to make your work shine for prime time. > > I like that, If it is not shining just because of 2/8 not applying now > then I fine with that. > Anyway, it is an experimental API, There is still room to change and > nothing is set and stone. > For me, the synergy between log/trace interface important as trace > needs to replace rte_log. Now that I better understand what rte_trace (and tracing in general) is, I believe rte_log cannot be replaced. I think we can write logs in traces, as a log option, but it should be just one possible output among others. I think everybody agree to use one constructor per log type and per trace type. We are ready to do this change for rte_trace first. This is your call to accept it or not, even if don't understand why you would like both to be done at the exact same time. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-05 20:10 ` Thomas Monjalon @ 2020-05-06 6:11 ` Jerin Jacob 0 siblings, 0 replies; 55+ messages in thread From: Jerin Jacob @ 2020-05-06 6:11 UTC (permalink / raw) To: Thomas Monjalon Cc: David Marchand, dpdk-dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Wed, May 6, 2020 at 1:40 AM Thomas Monjalon <thomas@monjalon.net> wrote: > > 05/05/2020 19:28, Jerin Jacob: > > On Tue, May 5, 2020 at 10:50 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > 05/05/2020 19:09, Jerin Jacob: > > > > On Tue, May 5, 2020 at 10:38 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon <thomas@monjalon.net> wrote: > > > > > > 05/05/2020 18:46, Jerin Jacob: > > > > > > > On Tue, May 5, 2020 at 9:58 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand <david.marchand@redhat.com> wrote: > > > > > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob <jerinjacobk@gmail.com> wrote: > > > > > > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > > > > > > a simple patch: > > > > > > > > > > > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > > > > > > with rte_log. > > > > > > > > > > > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > > > > > > also and more tracepoints. > > > > > > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > > > > > > well(Just make sure the direction is correct). > > > > > > > > > > > > > > > > > > > > Next steps: > > > > > > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > > > > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > > > > > > build and static build. > > > > > > > > > My results inline with your results aka negligible overhead. > > > > > > > > > > > > > > > > > > David, > > > > > > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > > > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > > > > > > If you are not planning to submit the rte_log patch then I can send > > > > > > > > > one for RC2 cleanup. > > > > > > > > > > > > > > > > It won't be possible for me. > > > > > > > > > > > > > > I can do that if we agree on the specifics. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > > > > > > as drivers are calling rte_log_register, then impose a default level > > > > > > > > without caring about what the user passed. > > > > > > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > > > > > > > > > > > What I wanted to do: > > > > > > > > - merge rte_log_register_and_pick_level() (experimental) into > > > > > > > > rte_log_register, doing this should be fine from my pov, > > > > > > > > - reconsider the relevance of a fallback logtype when registration fails, > > > > > > > > - shoot the default level per component thing: levels meaning is > > > > > > > > fragmented across the drivers/libraries because of it, but this will > > > > > > > > open a big box of stuff, > > > > > > > > > > > > > > This you are referring to internal implementation improvement. Right? > > > > > > > I was referring to remove the current clutter[1] > > > > > > > If we stick the following as the interface. Then you can do other > > > > > > > improvements when you get time > > > > > > > that won't change the consumer code or interference part. > > > > > > > > > > > > > > #define RTE_LOG_REGISTER(type, name, level) > > > > > > > > > > > > This discussion is interesting but out of scope for rte_trace. > > > > > > I am also interested in rte_log registration cleanup, > > > > > > but I know it is too much work for the last weeks of 20.05. > > > > > > > > > > > > As Olivier said about rte_trace, > > > > > > "Since it's a new API, it makes sense to make > > > > > > it as good as possible for the first version." > > > > > > > > > > > > So please let's conclude on this rte_trace patch for 20.05-rc2, > > > > > > and commit to fix rte_log registration in the first days of 20.08. > > > > > > > > > > Why not hold the trace registration patch 2/8 and apply rest for RC2. > > > > > Once we have synergy between the registration scheme between rte_log > > > > > and rte_trace > > > > > apply the patch for RC2. > > > > > > > > I meant, Once we have synergy between the registration scheme between > > > > rte_log and rte_trace > > > > apply the patch for _20.08_? > > > > > > Because of what I wrote above: > > > As Olivier said about rte_trace, > > > "Since it's a new API, it makes sense to make > > > it as good as possible for the first version." > > > > > > The intent is to show an API as simple as possible > > > in order to have a maximum of developers integrating it, > > > and getting more interesting feedbacks. > > > > > > In other words, we want to make your work shine for prime time. > > > > I like that, If it is not shining just because of 2/8 not applying now > > then I fine with that. > > Anyway, it is an experimental API, There is still room to change and > > nothing is set and stone. > > For me, the synergy between log/trace interface important as trace > > needs to replace rte_log. > > Now that I better understand what rte_trace (and tracing in general) is, > I believe rte_log cannot be replaced. > I think we can write logs in traces, as a log option, but it should be > just one possible output among others. IMO, log function can be implemented with trace. Not another way around. Functionality-wise we can replace/redirect logs are traces. At least at the registration point, semantically and syntax wise it can be similar. > > I think everybody agree to use one constructor per log type and > per trace type. > We are ready to do this change for rte_trace first. If we consider the constructor per log/trace is an improvement, I would like to do that first in rte_log and it has more consumers. And I am willing to send a patch for the following change across rte_log consumers. http://mails.dpdk.org/archives/dev/2020-May/166468.html I created the rte_trace registration mechanism similar to rte_log with community feedback on alignment and rte_trace and rte_log. I would like to maintain that. > This is your call to accept it or not, even if don't understand > why you would like both to be done at the exact same time. > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 2020-05-03 20:31 ` [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration David Marchand 2020-05-04 2:46 ` Jerin Jacob @ 2020-07-04 14:31 ` Jerin Jacob 2020-07-04 15:14 ` [dpdk-dev] [PATCH v2] " David Marchand 2 siblings, 0 replies; 55+ messages in thread From: Jerin Jacob @ 2020-07-04 14:31 UTC (permalink / raw) To: David Marchand Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > Signed-off-by: David Marchand <david.marchand@redhat.com> > --- > app/test/test_trace_register.c | 12 +- > doc/guides/prog_guide/trace_lib.rst | 12 +- > lib/librte_cryptodev/cryptodev_trace_points.c | 84 +++---- > .../common/eal_common_trace_points.c | 164 ++++++-------- > lib/librte_eal/include/rte_eal_trace.h | 122 +++++------ > lib/librte_eal/include/rte_trace_point.h | 14 +- > .../include/rte_trace_point_register.h | 6 +- > lib/librte_ethdev/ethdev_trace_points.c | 44 ++-- > lib/librte_eventdev/eventdev_trace_points.c | 205 +++++++----------- > lib/librte_mempool/mempool_trace_points.c | 124 ++++------- > 10 files changed, 309 insertions(+), 478 deletions(-) This needs to be rebased to ToT. Please merge to RC1 if possible. Acked-by: Jerin Jacob <jerinj@marvell.com> ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH v2] trace: simplify trace point registration 2020-05-03 20:31 ` [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration David Marchand 2020-05-04 2:46 ` Jerin Jacob 2020-07-04 14:31 ` Jerin Jacob @ 2020-07-04 15:14 ` David Marchand 2020-07-05 19:41 ` Thomas Monjalon 2 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-07-04 15:14 UTC (permalink / raw) To: dev Cc: thomas, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Jerin Jacob <jerinj@marvell.com> --- Changes since v1: - rebased on main branch, --- app/test/test_trace_register.c | 12 +- doc/guides/prog_guide/trace_lib.rst | 12 +- lib/librte_cryptodev/cryptodev_trace_points.c | 84 +++---- .../common/eal_common_trace_points.c | 164 ++++++-------- lib/librte_eal/include/rte_eal_trace.h | 122 +++++------ lib/librte_eal/include/rte_trace_point.h | 14 +- .../include/rte_trace_point_register.h | 6 +- lib/librte_ethdev/ethdev_trace_points.c | 44 ++-- lib/librte_eventdev/eventdev_trace_points.c | 205 +++++++----------- lib/librte_mempool/mempool_trace_points.c | 124 ++++------- 10 files changed, 309 insertions(+), 478 deletions(-) diff --git a/app/test/test_trace_register.c b/app/test/test_trace_register.c index b9372d3f9b..4891493687 100644 --- a/app/test/test_trace_register.c +++ b/app/test/test_trace_register.c @@ -6,13 +6,5 @@ #include "test_trace.h" -/* Define trace points */ -RTE_TRACE_POINT_DEFINE(app_dpdk_test_tp); -RTE_TRACE_POINT_DEFINE(app_dpdk_test_fp); - -RTE_INIT(register_valid_trace_points) -{ - RTE_TRACE_POINT_REGISTER(app_dpdk_test_tp, app.dpdk.test.tp); - RTE_TRACE_POINT_REGISTER(app_dpdk_test_fp, app.dpdk.test.fp); -} - +RTE_TRACE_POINT_REGISTER(app_dpdk_test_tp, app.dpdk.test.tp) +RTE_TRACE_POINT_REGISTER(app_dpdk_test_fp, app.dpdk.test.fp) diff --git a/doc/guides/prog_guide/trace_lib.rst b/doc/guides/prog_guide/trace_lib.rst index b6c6285779..9bbfd165d8 100644 --- a/doc/guides/prog_guide/trace_lib.rst +++ b/doc/guides/prog_guide/trace_lib.rst @@ -100,12 +100,7 @@ Register the tracepoint #include <my_tracepoint.h> - RTE_TRACE_POINT_DEFINE(app_trace_string); - - RTE_INIT(app_trace_init) - { - RTE_TRACE_POINT_REGISTER(app_trace_string, app.trace.string); - } + RTE_TRACE_POINT_REGISTER(app_trace_string, app.trace.string) The above code snippet registers the ``app_trace_string`` tracepoint to trace library. Here, the ``my_tracepoint.h`` is the header file @@ -118,9 +113,6 @@ There is no requirement for the tracepoint function and its name to be similar. However, it is recommended to have a similar name for a better naming convention. -The user must register the tracepoint before the ``rte_eal_init`` invocation. -The user can use the ``RTE_INIT`` construction scheme to achieve this. - .. note:: The ``rte_trace_point_register.h`` header must be included before any @@ -128,7 +120,7 @@ The user can use the ``RTE_INIT`` construction scheme to achieve this. .. note:: - The ``RTE_TRACE_POINT_DEFINE`` defines the placeholder for the + The ``RTE_TRACE_POINT_REGISTER`` defines the placeholder for the ``rte_trace_point_t`` tracepoint object. The user must export a ``__<trace_function_name>`` symbol in the library ``.map`` file for this tracepoint to be used out of the library, in shared builds. diff --git a/lib/librte_cryptodev/cryptodev_trace_points.c b/lib/librte_cryptodev/cryptodev_trace_points.c index 7672c7b99b..5d58951fd5 100644 --- a/lib/librte_cryptodev/cryptodev_trace_points.c +++ b/lib/librte_cryptodev/cryptodev_trace_points.c @@ -6,70 +6,50 @@ #include "rte_cryptodev_trace.h" -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_configure); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_start); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_stop); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_close); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_queue_pair_setup); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_pool_create); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_create); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_create); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_free); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_free); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_init); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_init); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_sym_session_clear); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_asym_session_clear); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_enqueue_burst); -RTE_TRACE_POINT_DEFINE(rte_cryptodev_trace_dequeue_burst); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_configure, + lib.cryptodev.configure) -RTE_INIT(cryptodev_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_configure, - lib.cryptodev.configure); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_start, + lib.cryptodev.start) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_start, - lib.cryptodev.start); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_stop, + lib.cryptodev.stop) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_stop, - lib.cryptodev.stop); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_close, + lib.cryptodev.close) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_close, - lib.cryptodev.close); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_queue_pair_setup, + lib.cryptodev.queue.pair.setup) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_queue_pair_setup, - lib.cryptodev.queue.pair.setup); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_pool_create, + lib.cryptodev.sym.pool.create) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_pool_create, - lib.cryptodev.sym.pool.create); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_create, + lib.cryptodev.sym.create) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_create, - lib.cryptodev.sym.create); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_create, + lib.cryptodev.asym.create) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_create, - lib.cryptodev.asym.create); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_free, + lib.cryptodev.sym.free) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_free, - lib.cryptodev.sym.free); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_free, + lib.cryptodev.asym.free) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_free, - lib.cryptodev.asym.free); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_init, + lib.cryptodev.sym.init) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_init, - lib.cryptodev.sym.init); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_init, + lib.cryptodev.asym.init) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_init, - lib.cryptodev.asym.init); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_clear, + lib.cryptodev.sym.clear) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_sym_session_clear, - lib.cryptodev.sym.clear); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_clear, + lib.cryptodev.asym.clear) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_session_clear, - lib.cryptodev.asym.clear); +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_enqueue_burst, + lib.cryptodev.enq.burst) - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_enqueue_burst, - lib.cryptodev.enq.burst); - - RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_dequeue_burst, - lib.cryptodev.deq.burst); -} +RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_dequeue_burst, + lib.cryptodev.deq.burst) diff --git a/lib/librte_eal/common/eal_common_trace_points.c b/lib/librte_eal/common/eal_common_trace_points.c index 4a8ce90888..292ec91bed 100644 --- a/lib/librte_eal/common/eal_common_trace_points.c +++ b/lib/librte_eal/common/eal_common_trace_points.c @@ -6,110 +6,70 @@ #include <rte_eal_trace.h> -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_void); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u64); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u32); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u16); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_u8); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i64); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i32); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i16); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_i8); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_int); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_long); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_float); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_double); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_ptr); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_str); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_generic_func); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_void, + lib.eal.generic.void) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u64, + lib.eal.generic.u64) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u32, + lib.eal.generic.u32) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u16, + lib.eal.generic.u16) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u8, + lib.eal.generic.u8) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i64, + lib.eal.generic.i64) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i32, + lib.eal.generic.i32) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i16, + lib.eal.generic.i16) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i8, + lib.eal.generic.i8) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_int, + lib.eal.generic.int) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_long, + lib.eal.generic.long) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_float, + lib.eal.generic.float) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_double, + lib.eal.generic.double) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_ptr, + lib.eal.generic.ptr) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_str, + lib.eal.generic.string) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func, + lib.eal.generic.func) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_alarm_set); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_alarm_cancel); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set, + lib.eal.alarm.set) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_cancel, + lib.eal.alarm.cancel) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_zmalloc); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_malloc); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_realloc); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_mem_free); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_zmalloc, + lib.eal.mem.zmalloc) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_malloc, + lib.eal.mem.malloc) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_realloc, + lib.eal.mem.realloc) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_free, + lib.eal.mem.free) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_memzone_reserve); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_memzone_lookup); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_memzone_free); +RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_reserve, + lib.eal.memzone.reserve) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_lookup, + lib.eal.memzone.lookup) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_free, + lib.eal.memzone.free) -RTE_TRACE_POINT_DEFINE(rte_eal_trace_thread_remote_launch); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_thread_lcore_ready); +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_DEFINE(rte_eal_trace_intr_callback_register); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_intr_callback_unregister); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_intr_enable); -RTE_TRACE_POINT_DEFINE(rte_eal_trace_intr_disable); - -RTE_INIT(eal_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_void, - lib.eal.generic.void); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u64, - lib.eal.generic.u64); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u32, - lib.eal.generic.u32); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u16, - lib.eal.generic.u16); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_u8, - lib.eal.generic.u8); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i64, - lib.eal.generic.i64); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i32, - lib.eal.generic.i32); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i16, - lib.eal.generic.i16); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_i8, - lib.eal.generic.i8); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_int, - lib.eal.generic.int); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_long, - lib.eal.generic.long); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_float, - lib.eal.generic.float); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_double, - lib.eal.generic.double); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_ptr, - lib.eal.generic.ptr); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_str, - lib.eal.generic.string); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func, - lib.eal.generic.func); - - RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set, - lib.eal.alarm.set); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_cancel, - lib.eal.alarm.cancel); - - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_zmalloc, - lib.eal.mem.zmalloc); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_malloc, - lib.eal.mem.malloc); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_realloc, - lib.eal.mem.realloc); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_mem_free, - lib.eal.mem.free); - - RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_reserve, - lib.eal.memzone.reserve); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_lookup, - lib.eal.memzone.lookup); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_memzone_free, - lib.eal.memzone.free); - - 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_intr_callback_register, - lib.eal.intr.register); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_unregister, - lib.eal.intr.unregister); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_enable, - lib.eal.intr.enable); - RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_disable, - lib.eal.intr.disable); -} +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_register, + lib.eal.intr.register) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_callback_unregister, + lib.eal.intr.unregister) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_enable, + lib.eal.intr.enable) +RTE_TRACE_POINT_REGISTER(rte_eal_trace_intr_disable, + lib.eal.intr.disable) diff --git a/lib/librte_eal/include/rte_eal_trace.h b/lib/librte_eal/include/rte_eal_trace.h index bcfef0cfaa..6b1a813c7b 100644 --- a/lib/librte_eal/include/rte_eal_trace.h +++ b/lib/librte_eal/include/rte_eal_trace.h @@ -19,6 +19,26 @@ extern "C" { #include <rte_interrupts.h> #include <rte_trace_point.h> +/* Alarm */ +RTE_TRACE_POINT( + rte_eal_trace_alarm_set, + RTE_TRACE_POINT_ARGS(uint64_t us, rte_eal_alarm_callback cb_fn, + void *cb_arg, int rc), + rte_trace_point_emit_u64(us); + rte_trace_point_emit_ptr(cb_fn); + rte_trace_point_emit_ptr(cb_arg); + rte_trace_point_emit_int(rc); +) + +RTE_TRACE_POINT( + rte_eal_trace_alarm_cancel, + RTE_TRACE_POINT_ARGS(rte_eal_alarm_callback cb_fn, void *cb_arg, + int count), + rte_trace_point_emit_ptr(cb_fn); + rte_trace_point_emit_ptr(cb_arg); + rte_trace_point_emit_int(count); +) + /* Generic */ RTE_TRACE_POINT( rte_eal_trace_generic_void, @@ -117,24 +137,52 @@ RTE_TRACE_POINT( #define RTE_EAL_TRACE_GENERIC_FUNC rte_eal_trace_generic_func(__func__) -/* Alarm */ +/* Interrupt */ RTE_TRACE_POINT( - rte_eal_trace_alarm_set, - RTE_TRACE_POINT_ARGS(uint64_t us, rte_eal_alarm_callback cb_fn, - void *cb_arg, int rc), - rte_trace_point_emit_u64(us); - rte_trace_point_emit_ptr(cb_fn); - rte_trace_point_emit_ptr(cb_arg); + rte_eal_trace_intr_callback_register, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, + rte_intr_callback_fn cb, void *cb_arg, int rc), rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); + rte_trace_point_emit_ptr(cb); + rte_trace_point_emit_ptr(cb_arg); ) - RTE_TRACE_POINT( - rte_eal_trace_alarm_cancel, - RTE_TRACE_POINT_ARGS(rte_eal_alarm_callback cb_fn, void *cb_arg, - int count), - rte_trace_point_emit_ptr(cb_fn); + rte_eal_trace_intr_callback_unregister, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, + rte_intr_callback_fn cb, void *cb_arg, int rc), + rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); + rte_trace_point_emit_ptr(cb); rte_trace_point_emit_ptr(cb_arg); - rte_trace_point_emit_int(count); +) +RTE_TRACE_POINT( + rte_eal_trace_intr_enable, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), + rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); +) +RTE_TRACE_POINT( + rte_eal_trace_intr_disable, + RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), + rte_trace_point_emit_int(rc); + rte_trace_point_emit_int(handle->vfio_dev_fd); + rte_trace_point_emit_int(handle->fd); + rte_trace_point_emit_int(handle->type); + rte_trace_point_emit_u32(handle->max_intr); + rte_trace_point_emit_u32(handle->nb_efd); ) /* Memory */ @@ -223,54 +271,6 @@ RTE_TRACE_POINT( rte_trace_point_emit_string(cpuset); ) -/* Interrupt */ -RTE_TRACE_POINT( - rte_eal_trace_intr_callback_register, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, - rte_intr_callback_fn cb, void *cb_arg, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); - rte_trace_point_emit_ptr(cb); - rte_trace_point_emit_ptr(cb_arg); -) -RTE_TRACE_POINT( - rte_eal_trace_intr_callback_unregister, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, - rte_intr_callback_fn cb, void *cb_arg, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); - rte_trace_point_emit_ptr(cb); - rte_trace_point_emit_ptr(cb_arg); -) -RTE_TRACE_POINT( - rte_eal_trace_intr_enable, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); -) -RTE_TRACE_POINT( - rte_eal_trace_intr_disable, - RTE_TRACE_POINT_ARGS(const struct rte_intr_handle *handle, int rc), - rte_trace_point_emit_int(rc); - rte_trace_point_emit_int(handle->vfio_dev_fd); - rte_trace_point_emit_int(handle->fd); - rte_trace_point_emit_int(handle->type); - rte_trace_point_emit_u32(handle->max_intr); - rte_trace_point_emit_u32(handle->nb_efd); -) - #ifdef __cplusplus } #endif diff --git a/lib/librte_eal/include/rte_trace_point.h b/lib/librte_eal/include/rte_trace_point.h index 377c2414aa..b039602772 100644 --- a/lib/librte_eal/include/rte_trace_point.h +++ b/lib/librte_eal/include/rte_trace_point.h @@ -34,10 +34,6 @@ extern "C" { /** The tracepoint object. */ typedef uint64_t rte_trace_point_t; -/** Macro to define the tracepoint. */ -#define RTE_TRACE_POINT_DEFINE(tp) \ -rte_trace_point_t __attribute__((section("__rte_trace_point"))) __##tp - /** * Macro to define the tracepoint arguments in RTE_TRACE_POINT macro. @@ -69,7 +65,7 @@ _tp _args \ * * @param tp * Tracepoint object. Before using the tracepoint, an application needs to - * define the tracepoint using RTE_TRACE_POINT_DEFINE macro. + * define the tracepoint using RTE_TRACE_POINT_REGISTER macro. * @param args * C function style input arguments to define the arguments to tracepoint * function. @@ -77,7 +73,7 @@ _tp _args \ * Define the payload of trace function. The payload will be formed using * rte_trace_point_emit_* macros. Use ";" delimiter between two payloads. * - * @see RTE_TRACE_POINT_ARGS, RTE_TRACE_POINT_DEFINE, rte_trace_point_emit_* + * @see RTE_TRACE_POINT_ARGS, RTE_TRACE_POINT_REGISTER, rte_trace_point_emit_* */ #define RTE_TRACE_POINT(tp, args, ...) \ __RTE_TRACE_POINT(generic, tp, args, __VA_ARGS__) @@ -90,7 +86,7 @@ _tp _args \ * * @param tp * Tracepoint object. Before using the tracepoint, an application needs to - * define the tracepoint using RTE_TRACE_POINT_DEFINE macro. + * define the tracepoint using RTE_TRACE_POINT_REGISTER macro. * @param args * C function style input arguments to define the arguments to tracepoint. * function. @@ -109,7 +105,7 @@ _tp _args \ * Register a tracepoint. * * @param trace - * The tracepoint object created using RTE_TRACE_POINT_DEFINE. + * The tracepoint object created using RTE_TRACE_POINT_REGISTER. * @param name * The name of the tracepoint object. * @return @@ -256,7 +252,7 @@ void __rte_trace_point_emit_field(size_t sz, const char *field, * Use RTE_TRACE_POINT_REGISTER macro for tracepoint registration. * * @param trace - * The tracepoint object created using RTE_TRACE_POINT_DEFINE. + * The tracepoint object created using RTE_TRACE_POINT_REGISTER. * @param name * The name of the tracepoint object. * @param register_fn diff --git a/lib/librte_eal/include/rte_trace_point_register.h b/lib/librte_eal/include/rte_trace_point_register.h index 4e7c25ba10..4f5c86552d 100644 --- a/lib/librte_eal/include/rte_trace_point_register.h +++ b/lib/librte_eal/include/rte_trace_point_register.h @@ -15,8 +15,12 @@ RTE_DECLARE_PER_LCORE(volatile int, trace_point_sz); #define RTE_TRACE_POINT_REGISTER(trace, name) \ +rte_trace_point_t __attribute__((section("__rte_trace_point"))) __##trace; \ +RTE_INIT(trace##_init) \ +{ \ __rte_trace_point_register(&__##trace, RTE_STR(name), \ - (void (*)(void)) trace) + (void (*)(void)) trace); \ +} #define __rte_trace_point_emit_header_generic(t) \ RTE_PER_LCORE(trace_point_sz) = __RTE_TRACE_EVENT_HEADER_SZ diff --git a/lib/librte_ethdev/ethdev_trace_points.c b/lib/librte_ethdev/ethdev_trace_points.c index 722578c1c4..2919409a15 100644 --- a/lib/librte_ethdev/ethdev_trace_points.c +++ b/lib/librte_ethdev/ethdev_trace_points.c @@ -6,38 +6,26 @@ #include <rte_ethdev_trace.h> -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_configure); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_rxq_setup); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_txq_setup); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_start); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_stop); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_close); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_rx_burst); -RTE_TRACE_POINT_DEFINE(rte_ethdev_trace_tx_burst); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_configure, + lib.ethdev.configure) -RTE_INIT(ethdev_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_configure, - lib.ethdev.configure); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rxq_setup, + lib.ethdev.rxq.setup) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rxq_setup, - lib.ethdev.rxq.setup); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_txq_setup, + lib.ethdev.txq.setup) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_txq_setup, - lib.ethdev.txq.setup); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_start, + lib.ethdev.start) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_start, - lib.ethdev.start); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_stop, + lib.ethdev.stop) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_stop, - lib.ethdev.stop); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_close, + lib.ethdev.close) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_close, - lib.ethdev.close); +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rx_burst, + lib.ethdev.rx.burst) - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rx_burst, - lib.ethdev.rx.burst); - - RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_tx_burst, - lib.ethdev.tx.burst); -} +RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_tx_burst, + lib.ethdev.tx.burst) diff --git a/lib/librte_eventdev/eventdev_trace_points.c b/lib/librte_eventdev/eventdev_trace_points.c index 3c06087143..1a0ccc4481 100644 --- a/lib/librte_eventdev/eventdev_trace_points.c +++ b/lib/librte_eventdev/eventdev_trace_points.c @@ -7,167 +7,114 @@ #include "rte_eventdev_trace.h" /* Eventdev trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_configure); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_queue_setup); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_port_setup); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_port_link); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_port_unlink); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_stop); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_close); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_enq_burst); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_deq_burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_configure, + lib.eventdev.configure) -/* Eventdev Rx adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_queue_add); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_queue_del); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_rx_adapter_stop); - -/* Eventdev Tx adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_queue_add); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_queue_del); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_stop); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_eth_tx_adapter_enqueue); - -/* Eventdev Timer adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_stop); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_arm_burst); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_arm_tmo_tick_burst); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_timer_cancel_burst); - -/* Eventdev Crypto adapter trace points */ -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_create); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_free); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_queue_pair_add); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_queue_pair_del); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_start); -RTE_TRACE_POINT_DEFINE(rte_eventdev_trace_crypto_adapter_stop); - -RTE_INIT(eventdev_trace_init) -{ - /* Eventdev trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_configure, - lib.eventdev.configure); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_queue_setup, + lib.eventdev.queue.setup) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_queue_setup, - lib.eventdev.queue.setup); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_setup, + lib.eventdev.port.setup) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_setup, - lib.eventdev.port.setup); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_link, + lib.eventdev.port.link) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_link, - lib.eventdev.port.link); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_unlink, + lib.eventdev.port.unlink) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_port_unlink, - lib.eventdev.port.unlink); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_start, + lib.eventdev.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_start, - lib.eventdev.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_stop, + lib.eventdev.stop) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_stop, - lib.eventdev.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_close, + lib.eventdev.close) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_close, - lib.eventdev.close); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_enq_burst, + lib.eventdev.enq.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_enq_burst, - lib.eventdev.enq.burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_deq_burst, + lib.eventdev.deq.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_deq_burst, - lib.eventdev.deq.burst); - - - /* Eventdev Rx adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_create, - lib.eventdev.rx.adapter.create); - - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_free, - lib.eventdev.rx.adapter.free); +/* Eventdev Rx adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_create, + lib.eventdev.rx.adapter.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_add, - lib.eventdev.rx.adapter.queue.add); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_free, + lib.eventdev.rx.adapter.free) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_del, - lib.eventdev.rx.adapter.queue.del); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_add, + lib.eventdev.rx.adapter.queue.add) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_start, - lib.eventdev.rx.adapter.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_queue_del, + lib.eventdev.rx.adapter.queue.del) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_stop, - lib.eventdev.rx.adapter.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_start, + lib.eventdev.rx.adapter.start) - /* Eventdev Tx adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_create, - lib.eventdev.tx.adapter.create); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_rx_adapter_stop, + lib.eventdev.rx.adapter.stop) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_free, - lib.eventdev.tx.adapter.free); +/* Eventdev Tx adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_create, + lib.eventdev.tx.adapter.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_add, - lib.eventdev.tx.adapter.queue.add); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_free, + lib.eventdev.tx.adapter.free) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_del, - lib.eventdev.tx.adapter.queue.del); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_add, + lib.eventdev.tx.adapter.queue.add) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_start, - lib.eventdev.tx.adapter.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_queue_del, + lib.eventdev.tx.adapter.queue.del) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_stop, - lib.eventdev.tx.adapter.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_start, + lib.eventdev.tx.adapter.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_enqueue, - lib.eventdev.tx.adapter.enq); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_stop, + lib.eventdev.tx.adapter.stop) +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_eth_tx_adapter_enqueue, + lib.eventdev.tx.adapter.enq) - /* Eventdev Timer adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_create, - lib.eventdev.timer.create); +/* Eventdev Timer adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_create, + lib.eventdev.timer.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_start, - lib.eventdev.timer.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_start, + lib.eventdev.timer.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_stop, - lib.eventdev.timer.stop); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_stop, + lib.eventdev.timer.stop) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_free, - lib.eventdev.timer.free); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_adapter_free, + lib.eventdev.timer.free) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_burst, - lib.eventdev.timer.burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_burst, + lib.eventdev.timer.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_tmo_tick_burst, - lib.eventdev.timer.tick.burst); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_arm_tmo_tick_burst, + lib.eventdev.timer.tick.burst) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_cancel_burst, - lib.eventdev.timer.cancel); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_timer_cancel_burst, + lib.eventdev.timer.cancel) - /* Eventdev Crypto adapter trace points */ - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_create, - lib.eventdev.crypto.create); +/* Eventdev Crypto adapter trace points */ +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_create, + lib.eventdev.crypto.create) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_free, - lib.eventdev.crypto.free); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_free, + lib.eventdev.crypto.free) - RTE_TRACE_POINT_REGISTER( - rte_eventdev_trace_crypto_adapter_queue_pair_add, - lib.eventdev.crypto.queue.add); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_queue_pair_add, + lib.eventdev.crypto.queue.add) - RTE_TRACE_POINT_REGISTER( - rte_eventdev_trace_crypto_adapter_queue_pair_del, - lib.eventdev.crypto.queue.del); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_queue_pair_del, + lib.eventdev.crypto.queue.del) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_start, - lib.eventdev.crypto.start); +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_start, + lib.eventdev.crypto.start) - RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_stop, - lib.eventdev.crypto.stop); -} +RTE_TRACE_POINT_REGISTER(rte_eventdev_trace_crypto_adapter_stop, + lib.eventdev.crypto.stop) diff --git a/lib/librte_mempool/mempool_trace_points.c b/lib/librte_mempool/mempool_trace_points.c index df4368b173..4ad76deb34 100644 --- a/lib/librte_mempool/mempool_trace_points.c +++ b/lib/librte_mempool/mempool_trace_points.c @@ -6,102 +6,74 @@ #include "rte_mempool_trace.h" -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_dequeue_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_dequeue_contig_blocks); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_enqueue_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_generic_put); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_put_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_generic_get); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_get_bulk); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_get_contig_blocks); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_create); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_create_empty); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_free); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_iova); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_virt); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_default); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_populate_anon); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_cache_create); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_cache_free); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_default_cache); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_get_page_size); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_cache_flush); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_populate); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_alloc); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_ops_free); -RTE_TRACE_POINT_DEFINE(rte_mempool_trace_set_ops_byname); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_bulk, + lib.mempool.ops.deq.bulk) -RTE_INIT(mempool_trace_init) -{ - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_bulk, - lib.mempool.ops.deq.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_contig_blocks, + lib.mempool.ops.deq.contig) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_dequeue_contig_blocks, - lib.mempool.ops.deq.contig); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_enqueue_bulk, + lib.mempool.ops.enq.bulk) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_enqueue_bulk, - lib.mempool.ops.enq.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_put, + lib.mempool.generic.put) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_put, - lib.mempool.generic.put); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_put_bulk, + lib.mempool.put.bulk) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_put_bulk, - lib.mempool.put.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_get, + lib.mempool.generic.get) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_generic_get, - lib.mempool.generic.get); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_bulk, + lib.mempool.get.bulk) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_bulk, - lib.mempool.get.bulk); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_contig_blocks, + lib.mempool.get.blocks) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_contig_blocks, - lib.mempool.get.blocks); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create, + lib.mempool.create) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create, - lib.mempool.create); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create_empty, + lib.mempool.create.empty) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_create_empty, - lib.mempool.create.empty); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_free, + lib.mempool.free) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_free, - lib.mempool.free); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_iova, + lib.mempool.populate.iova) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_iova, - lib.mempool.populate.iova); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_virt, + lib.mempool.populate.virt) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_virt, - lib.mempool.populate.virt); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_default, + lib.mempool.populate.default) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_default, - lib.mempool.populate.default); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_anon, + lib.mempool.populate.anon) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_populate_anon, - lib.mempool.populate.anon); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_create, + lib.mempool.cache_create) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_create, - lib.mempool.cache_create); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_free, + lib.mempool.cache.free) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_free, - lib.mempool.cache.free); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_default_cache, + lib.mempool.default.cache) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_default_cache, - lib.mempool.default.cache); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_page_size, + lib.mempool.get.page.size) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_get_page_size, - lib.mempool.get.page.size); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_flush, + lib.mempool.cache.flush) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_cache_flush, - lib.mempool.cache.flush); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_populate, + lib.mempool.ops.populate) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_populate, - lib.mempool.ops.populate); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_alloc, + lib.mempool.ops.alloc) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_alloc, - lib.mempool.ops.alloc); +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_free, + lib.mempool.ops.free) - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_ops_free, - lib.mempool.ops.free); - - RTE_TRACE_POINT_REGISTER(rte_mempool_trace_set_ops_byname, - lib.mempool.set.ops.byname); -} +RTE_TRACE_POINT_REGISTER(rte_mempool_trace_set_ops_byname, + lib.mempool.set.ops.byname) -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH v2] trace: simplify trace point registration 2020-07-04 15:14 ` [dpdk-dev] [PATCH v2] " David Marchand @ 2020-07-05 19:41 ` Thomas Monjalon 0 siblings, 0 replies; 55+ messages in thread From: Thomas Monjalon @ 2020-07-05 19:41 UTC (permalink / raw) To: David Marchand Cc: dev, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz 04/07/2020 17:14, David Marchand: > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > Signed-off-by: David Marchand <david.marchand@redhat.com> > Acked-by: Jerin Jacob <jerinj@marvell.com> Applied, thanks ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 3/8] trace: simplify trace point headers 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand 2020-05-03 20:31 ` [dpdk-dev] [PATCH 1/8] cryptodev: fix trace points registration David Marchand 2020-05-03 20:31 ` [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 6:12 ` Jerin Jacob 2020-05-03 20:31 ` [dpdk-dev] [PATCH 4/8] trace: avoid confusion on optarg David Marchand ` (5 subsequent siblings) 8 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev Cc: thomas, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz Invert the current trace point headers logic by making rte_trace_point_register.h include rte_trace_point.h. There is no more need for a RTE_TRACE_POINT_REGISTER_SELECT special macro since including rte_trace_point_register.h itself means we want to register trace points. The unexplained "provider" notion is removed from the documentation and rte_trace_point_provider.h is merged into rte_trace_point.h. Signed-off-by: David Marchand <david.marchand@redhat.com> --- app/test/test_trace_register.c | 3 +- doc/guides/prog_guide/trace_lib.rst | 19 ++- lib/librte_cryptodev/cryptodev_trace_points.c | 2 +- .../common/eal_common_trace_points.c | 2 +- lib/librte_eal/include/meson.build | 1 - lib/librte_eal/include/rte_trace_point.h | 140 +++++++++++++++--- .../include/rte_trace_point_provider.h | 131 ---------------- .../include/rte_trace_point_register.h | 9 +- lib/librte_ethdev/ethdev_trace_points.c | 2 +- lib/librte_eventdev/eventdev_trace_points.c | 2 +- lib/librte_mempool/mempool_trace_points.c | 2 +- 11 files changed, 142 insertions(+), 171 deletions(-) delete mode 100644 lib/librte_eal/include/rte_trace_point_provider.h diff --git a/app/test/test_trace_register.c b/app/test/test_trace_register.c index 7feacfbabc..4891493687 100644 --- a/app/test/test_trace_register.c +++ b/app/test/test_trace_register.c @@ -1,7 +1,8 @@ /* SPDX-License-Identifier: BSD-3-Clause * Copyright(C) 2020 Marvell International Ltd. */ -#define RTE_TRACE_POINT_REGISTER_SELECT + +#include <rte_trace_point_register.h> #include "test_trace.h" diff --git a/doc/guides/prog_guide/trace_lib.rst b/doc/guides/prog_guide/trace_lib.rst index 9cad4ff4ac..9bbfd165d8 100644 --- a/doc/guides/prog_guide/trace_lib.rst +++ b/doc/guides/prog_guide/trace_lib.rst @@ -52,10 +52,10 @@ How to add a tracepoint? This section steps you through the details of adding a simple tracepoint. -.. _create_provider_header_file: +.. _create_tracepoint_header_file: -Create the tracepoint provider header file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Create the tracepoint header file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. code-block:: c @@ -96,16 +96,15 @@ Register the tracepoint .. code-block:: c - /* Select tracepoint register macros */ - #define RTE_TRACE_POINT_REGISTER_SELECT + #include <rte_trace_point_register.h> - #include <my_tracepoint_provider.h> + #include <my_tracepoint.h> RTE_TRACE_POINT_REGISTER(app_trace_string, app.trace.string) The above code snippet registers the ``app_trace_string`` tracepoint to -trace library. Here, the ``my_tracepoint_provider.h`` is the header file -that the user created in the first step :ref:`create_provider_header_file`. +trace library. Here, the ``my_tracepoint.h`` is the header file +that the user created in the first step :ref:`create_tracepoint_header_file`. The second argument for the ``RTE_TRACE_POINT_REGISTER`` is the name for the tracepoint. This string will be used for tracepoint lookup or regular @@ -116,8 +115,8 @@ convention. .. note:: - The ``RTE_TRACE_POINT_REGISTER_SELECT`` must be defined before including the - header for the tracepoint registration to work properly. + The ``rte_trace_point_register.h`` header must be included before any + inclusion of the ``rte_trace_point.h`` header. .. note:: diff --git a/lib/librte_cryptodev/cryptodev_trace_points.c b/lib/librte_cryptodev/cryptodev_trace_points.c index aa31103404..5d58951fd5 100644 --- a/lib/librte_cryptodev/cryptodev_trace_points.c +++ b/lib/librte_cryptodev/cryptodev_trace_points.c @@ -2,7 +2,7 @@ * Copyright(C) 2020 Marvell International Ltd. */ -#define RTE_TRACE_POINT_REGISTER_SELECT +#include <rte_trace_point_register.h> #include "rte_cryptodev_trace.h" diff --git a/lib/librte_eal/common/eal_common_trace_points.c b/lib/librte_eal/common/eal_common_trace_points.c index d1d8d1875c..292ec91bed 100644 --- a/lib/librte_eal/common/eal_common_trace_points.c +++ b/lib/librte_eal/common/eal_common_trace_points.c @@ -2,7 +2,7 @@ * Copyright(C) 2020 Marvell International Ltd. */ -#define RTE_TRACE_POINT_REGISTER_SELECT +#include <rte_trace_point_register.h> #include <rte_eal_trace.h> diff --git a/lib/librte_eal/include/meson.build b/lib/librte_eal/include/meson.build index e9537c91f9..13315bfcec 100644 --- a/lib/librte_eal/include/meson.build +++ b/lib/librte_eal/include/meson.build @@ -43,7 +43,6 @@ headers += files( 'rte_time.h', 'rte_trace.h', 'rte_trace_point.h', - 'rte_trace_point_provider.h', 'rte_trace_point_register.h', 'rte_uuid.h', 'rte_version.h', diff --git a/lib/librte_eal/include/rte_trace_point.h b/lib/librte_eal/include/rte_trace_point.h index dbd648c054..942f458e7a 100644 --- a/lib/librte_eal/include/rte_trace_point.h +++ b/lib/librte_eal/include/rte_trace_point.h @@ -96,17 +96,6 @@ _tp _args \ #ifdef __DOXYGEN__ -/** - * Macro to select rte_trace_point_emit_* definition for trace register function - * - * rte_trace_point_emit_* emits different definitions for trace function. - * Application must define RTE_TRACE_POINT_REGISTER_SELECT before including - * rte_trace_point.h in the C file where RTE_TRACE_POINT_REGISTER used. - * - * @see RTE_TRACE_POINT_REGISTER - */ -#define RTE_TRACE_POINT_REGISTER_SELECT - /** * Register a tracepoint. * @@ -117,8 +106,6 @@ _tp _args \ * @return * - 0: Successfully registered the tracepoint. * - <0: Failure to register the tracepoint. - * - * @see RTE_TRACE_POINT_REGISTER_SELECT */ #define RTE_TRACE_POINT_REGISTER(trace, name) @@ -271,13 +258,128 @@ __rte_experimental int __rte_trace_point_register(rte_trace_point_t *trace, const char *name, void (*register_fn)(void)); -#ifdef RTE_TRACE_POINT_REGISTER_SELECT -#include <rte_trace_point_register.h> +#ifndef __DOXYGEN__ + +#ifndef _RTE_TRACE_POINT_REGISTER_H_ +#ifdef ALLOW_EXPERIMENTAL_API + +#include <rte_branch_prediction.h> +#include <rte_cycles.h> +#include <rte_per_lcore.h> +#include <rte_string_fns.h> +#include <rte_uuid.h> + +#define __RTE_TRACE_EVENT_HEADER_ID_SHIFT (48) + +#define __RTE_TRACE_FIELD_SIZE_SHIFT 0 +#define __RTE_TRACE_FIELD_SIZE_MASK (0xffffULL << __RTE_TRACE_FIELD_SIZE_SHIFT) +#define __RTE_TRACE_FIELD_ID_SHIFT (16) +#define __RTE_TRACE_FIELD_ID_MASK (0xffffULL << __RTE_TRACE_FIELD_ID_SHIFT) +#define __RTE_TRACE_FIELD_ENABLE_MASK (1ULL << 63) +#define __RTE_TRACE_FIELD_ENABLE_DISCARD (1ULL << 62) + +struct __rte_trace_stream_header { + uint32_t magic; + rte_uuid_t uuid; + uint32_t lcore_id; + char thread_name[__RTE_TRACE_EMIT_STRING_LEN_MAX]; +} __rte_packed; + +struct __rte_trace_header { + uint32_t offset; + uint32_t len; + struct __rte_trace_stream_header stream_header; + uint8_t mem[]; +}; + +RTE_DECLARE_PER_LCORE(void *, trace_mem); + +static __rte_always_inline void * +__rte_trace_mem_get(uint64_t in) +{ + struct __rte_trace_header *trace = RTE_PER_LCORE(trace_mem); + const uint16_t sz = in & __RTE_TRACE_FIELD_SIZE_MASK; + + /* Trace memory is not initialized for this thread */ + if (unlikely(trace == NULL)) { + __rte_trace_mem_per_thread_alloc(); + trace = RTE_PER_LCORE(trace_mem); + if (unlikely(trace == NULL)) + return NULL; + } + /* Check the wrap around case */ + uint32_t offset = trace->offset; + if (unlikely((offset + sz) >= trace->len)) { + /* Disable the trace event if it in DISCARD mode */ + if (unlikely(in & __RTE_TRACE_FIELD_ENABLE_DISCARD)) + return NULL; + + offset = 0; + } + /* Align to event header size */ + offset = RTE_ALIGN_CEIL(offset, __RTE_TRACE_EVENT_HEADER_SZ); + void *mem = RTE_PTR_ADD(&trace->mem[0], offset); + offset += sz; + trace->offset = offset; + + return mem; +} + +static __rte_always_inline void * +__rte_trace_point_emit_ev_header(void *mem, uint64_t in) +{ + uint64_t val; + + /* Event header [63:0] = id [63:48] | timestamp [47:0] */ + val = rte_get_tsc_cycles() & + ~(0xffffULL << __RTE_TRACE_EVENT_HEADER_ID_SHIFT); + val |= ((in & __RTE_TRACE_FIELD_ID_MASK) << + (__RTE_TRACE_EVENT_HEADER_ID_SHIFT - __RTE_TRACE_FIELD_ID_SHIFT)); + + *(uint64_t *)mem = val; + return RTE_PTR_ADD(mem, __RTE_TRACE_EVENT_HEADER_SZ); +} + +#define __rte_trace_point_emit_header_generic(t) \ +void *mem; \ +do { \ + const uint64_t val = __atomic_load_n(t, __ATOMIC_ACQUIRE); \ + if (likely(!(val & __RTE_TRACE_FIELD_ENABLE_MASK))) \ + return; \ + mem = __rte_trace_mem_get(val); \ + if (unlikely(mem == NULL)) \ + return; \ + mem = __rte_trace_point_emit_ev_header(mem, val); \ +} while (0) + +#define __rte_trace_point_emit_header_fp(t) \ + if (!__rte_trace_point_fp_is_enabled()) \ + return; \ + __rte_trace_point_emit_header_generic(t) + +#define __rte_trace_point_emit(in, type) \ +do { \ + memcpy(mem, &(in), sizeof(in)); \ + mem = RTE_PTR_ADD(mem, sizeof(in)); \ +} while (0) + +#define rte_trace_point_emit_string(in) \ +do { \ + if (unlikely(in == NULL)) \ + return; \ + rte_strscpy(mem, in, __RTE_TRACE_EMIT_STRING_LEN_MAX); \ + mem = RTE_PTR_ADD(mem, __RTE_TRACE_EMIT_STRING_LEN_MAX); \ +} while (0) + #else -#include <rte_trace_point_provider.h> -#endif -#ifndef __DOXYGEN__ +#define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t) +#define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) +#define __rte_trace_point_emit(in, type) RTE_SET_USED(in) +#define rte_trace_point_emit_string(in) RTE_SET_USED(in) + +#endif /* ALLOW_EXPERIMENTAL_API */ +#endif #define rte_trace_point_emit_u64(in) __rte_trace_point_emit(in, uint64_t) #define rte_trace_point_emit_i64(in) __rte_trace_point_emit(in, int64_t) @@ -293,7 +395,7 @@ int __rte_trace_point_register(rte_trace_point_t *trace, const char *name, #define rte_trace_point_emit_double(in) __rte_trace_point_emit(in, double) #define rte_trace_point_emit_ptr(in) __rte_trace_point_emit(in, uintptr_t) -#endif +#endif /* __DOXYGEN__ */ #ifdef __cplusplus } diff --git a/lib/librte_eal/include/rte_trace_point_provider.h b/lib/librte_eal/include/rte_trace_point_provider.h deleted file mode 100644 index bf53282f38..0000000000 --- a/lib/librte_eal/include/rte_trace_point_provider.h +++ /dev/null @@ -1,131 +0,0 @@ -/* SPDX-License-Identifier: BSD-3-Clause - * Copyright(C) 2020 Marvell International Ltd. - */ - -#ifndef _RTE_TRACE_POINT_H_ -#error do not include this file directly, use <rte_trace_point.h> instead -#endif - -#ifndef _RTE_TRACE_POINT_PROVIDER_H_ -#define _RTE_TRACE_POINT_PROVIDER_H_ - -#ifdef ALLOW_EXPERIMENTAL_API - -#include <rte_branch_prediction.h> -#include <rte_cycles.h> -#include <rte_per_lcore.h> -#include <rte_string_fns.h> -#include <rte_uuid.h> - -#define __RTE_TRACE_EVENT_HEADER_ID_SHIFT (48) - -#define __RTE_TRACE_FIELD_SIZE_SHIFT 0 -#define __RTE_TRACE_FIELD_SIZE_MASK (0xffffULL << __RTE_TRACE_FIELD_SIZE_SHIFT) -#define __RTE_TRACE_FIELD_ID_SHIFT (16) -#define __RTE_TRACE_FIELD_ID_MASK (0xffffULL << __RTE_TRACE_FIELD_ID_SHIFT) -#define __RTE_TRACE_FIELD_ENABLE_MASK (1ULL << 63) -#define __RTE_TRACE_FIELD_ENABLE_DISCARD (1ULL << 62) - -struct __rte_trace_stream_header { - uint32_t magic; - rte_uuid_t uuid; - uint32_t lcore_id; - char thread_name[__RTE_TRACE_EMIT_STRING_LEN_MAX]; -} __rte_packed; - -struct __rte_trace_header { - uint32_t offset; - uint32_t len; - struct __rte_trace_stream_header stream_header; - uint8_t mem[]; -}; - -RTE_DECLARE_PER_LCORE(void *, trace_mem); - -static __rte_always_inline void * -__rte_trace_mem_get(uint64_t in) -{ - struct __rte_trace_header *trace = RTE_PER_LCORE(trace_mem); - const uint16_t sz = in & __RTE_TRACE_FIELD_SIZE_MASK; - - /* Trace memory is not initialized for this thread */ - if (unlikely(trace == NULL)) { - __rte_trace_mem_per_thread_alloc(); - trace = RTE_PER_LCORE(trace_mem); - if (unlikely(trace == NULL)) - return NULL; - } - /* Check the wrap around case */ - uint32_t offset = trace->offset; - if (unlikely((offset + sz) >= trace->len)) { - /* Disable the trace event if it in DISCARD mode */ - if (unlikely(in & __RTE_TRACE_FIELD_ENABLE_DISCARD)) - return NULL; - - offset = 0; - } - /* Align to event header size */ - offset = RTE_ALIGN_CEIL(offset, __RTE_TRACE_EVENT_HEADER_SZ); - void *mem = RTE_PTR_ADD(&trace->mem[0], offset); - offset += sz; - trace->offset = offset; - - return mem; -} - -static __rte_always_inline void * -__rte_trace_point_emit_ev_header(void *mem, uint64_t in) -{ - uint64_t val; - - /* Event header [63:0] = id [63:48] | timestamp [47:0] */ - val = rte_get_tsc_cycles() & - ~(0xffffULL << __RTE_TRACE_EVENT_HEADER_ID_SHIFT); - val |= ((in & __RTE_TRACE_FIELD_ID_MASK) << - (__RTE_TRACE_EVENT_HEADER_ID_SHIFT - __RTE_TRACE_FIELD_ID_SHIFT)); - - *(uint64_t *)mem = val; - return RTE_PTR_ADD(mem, __RTE_TRACE_EVENT_HEADER_SZ); -} - -#define __rte_trace_point_emit_header_generic(t) \ -void *mem; \ -do { \ - const uint64_t val = __atomic_load_n(t, __ATOMIC_ACQUIRE); \ - if (likely(!(val & __RTE_TRACE_FIELD_ENABLE_MASK))) \ - return; \ - mem = __rte_trace_mem_get(val); \ - if (unlikely(mem == NULL)) \ - return; \ - mem = __rte_trace_point_emit_ev_header(mem, val); \ -} while (0) - -#define __rte_trace_point_emit_header_fp(t) \ - if (!__rte_trace_point_fp_is_enabled()) \ - return; \ - __rte_trace_point_emit_header_generic(t) - -#define __rte_trace_point_emit(in, type) \ -do { \ - memcpy(mem, &(in), sizeof(in)); \ - mem = RTE_PTR_ADD(mem, sizeof(in)); \ -} while (0) - -#define rte_trace_point_emit_string(in) \ -do { \ - if (unlikely(in == NULL)) \ - return; \ - rte_strscpy(mem, in, __RTE_TRACE_EMIT_STRING_LEN_MAX); \ - mem = RTE_PTR_ADD(mem, __RTE_TRACE_EMIT_STRING_LEN_MAX); \ -} while (0) - -#else - -#define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t) -#define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) -#define __rte_trace_point_emit(in, type) RTE_SET_USED(in) -#define rte_trace_point_emit_string(in) RTE_SET_USED(in) - -#endif - -#endif /* _RTE_TRACE_POINT_PROVIDER_H_ */ diff --git a/lib/librte_eal/include/rte_trace_point_register.h b/lib/librte_eal/include/rte_trace_point_register.h index 26e383a8bb..548fe4dab3 100644 --- a/lib/librte_eal/include/rte_trace_point_register.h +++ b/lib/librte_eal/include/rte_trace_point_register.h @@ -2,14 +2,15 @@ * Copyright(C) 2020 Marvell International Ltd. */ -#ifndef _RTE_TRACE_POINT_H_ -#error do not include this file directly, use <rte_trace_point.h> instead -#endif - #ifndef _RTE_TRACE_POINT_REGISTER_H_ #define _RTE_TRACE_POINT_REGISTER_H_ +#ifdef _RTE_TRACE_POINT_H_ +#error for tracepoint registration, include this file first before <rte_trace_point.h> +#endif + #include <rte_per_lcore.h> +#include <rte_trace_point.h> RTE_DECLARE_PER_LCORE(volatile int, trace_point_sz); diff --git a/lib/librte_ethdev/ethdev_trace_points.c b/lib/librte_ethdev/ethdev_trace_points.c index 5be377521c..2919409a15 100644 --- a/lib/librte_ethdev/ethdev_trace_points.c +++ b/lib/librte_ethdev/ethdev_trace_points.c @@ -2,7 +2,7 @@ * Copyright(C) 2020 Marvell International Ltd. */ -#define RTE_TRACE_POINT_REGISTER_SELECT +#include <rte_trace_point_register.h> #include <rte_ethdev_trace.h> diff --git a/lib/librte_eventdev/eventdev_trace_points.c b/lib/librte_eventdev/eventdev_trace_points.c index 221a62b71c..1a0ccc4481 100644 --- a/lib/librte_eventdev/eventdev_trace_points.c +++ b/lib/librte_eventdev/eventdev_trace_points.c @@ -2,7 +2,7 @@ * Copyright(C) 2020 Marvell International Ltd. */ -#define RTE_TRACE_POINT_REGISTER_SELECT +#include <rte_trace_point_register.h> #include "rte_eventdev_trace.h" diff --git a/lib/librte_mempool/mempool_trace_points.c b/lib/librte_mempool/mempool_trace_points.c index 3dac0bc536..4ad76deb34 100644 --- a/lib/librte_mempool/mempool_trace_points.c +++ b/lib/librte_mempool/mempool_trace_points.c @@ -2,7 +2,7 @@ * Copyright(C) 2020 Marvell International Ltd. */ -#define RTE_TRACE_POINT_REGISTER_SELECT +#include <rte_trace_point_register.h> #include "rte_mempool_trace.h" -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 3/8] trace: simplify trace point headers 2020-05-03 20:31 ` [dpdk-dev] [PATCH 3/8] trace: simplify trace point headers David Marchand @ 2020-05-04 6:12 ` Jerin Jacob 0 siblings, 0 replies; 55+ messages in thread From: Jerin Jacob @ 2020-05-04 6:12 UTC (permalink / raw) To: David Marchand Cc: dpdk-dev, Thomas Monjalon, Jerin Jacob, Sunil Kumar Kori, John McNamara, Marko Kovacevic, Declan Doherty, Ferruh Yigit, Andrew Rybchenko, Olivier Matz On Mon, May 4, 2020 at 2:02 AM David Marchand <david.marchand@redhat.com> wrote: > > Invert the current trace point headers logic by making > rte_trace_point_register.h include rte_trace_point.h. > > There is no more need for a RTE_TRACE_POINT_REGISTER_SELECT special macro > since including rte_trace_point_register.h itself means we want to > register trace points. > > The unexplained "provider" notion is removed from the documentation and > rte_trace_point_provider.h is merged into rte_trace_point.h. > > Signed-off-by: David Marchand <david.marchand@redhat.com> > > @@ -271,13 +258,128 @@ __rte_experimental > int __rte_trace_point_register(rte_trace_point_t *trace, const char *name, > void (*register_fn)(void)); > > -#ifdef RTE_TRACE_POINT_REGISTER_SELECT > -#include <rte_trace_point_register.h> > +#ifndef __DOXYGEN__ > + > +#ifndef _RTE_TRACE_POINT_REGISTER_H_ > +#ifdef ALLOW_EXPERIMENTAL_API > + > +#include <rte_branch_prediction.h> > +#include <rte_cycles.h> > +#include <rte_per_lcore.h> > +#include <rte_string_fns.h> > +#include <rte_uuid.h> I think, we can move this header file to the beginning of the file. > > -#ifndef __DOXYGEN__ > +#define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t) > +#define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) > +#define __rte_trace_point_emit(in, type) RTE_SET_USED(in) > +#define rte_trace_point_emit_string(in) RTE_SET_USED(in) > + > +#endif /* ALLOW_EXPERIMENTAL_API */ > +#endif Please add / *_RTE_TRACE_POINT_REGISTER_H_ */ for this endif Please fix the below checkpatch warnings. 1) WARNING:LONG_LINE: line over 80 characters #449: FILE: lib/librte_eal/include/rte_trace_point_register.h:9: +#error for tracepoint registration, include this file first before <rte_trace_point.h> 2) WARNING:LONG_LINE: line over 80 characters #237: FILE: lib/librte_eal/include/rte_trace_point.h:337: + (__RTE_TRACE_EVENT_HEADER_ID_SHIFT - __RTE_TRACE_FIELD_ID_SHIFT)); With the above change, Acked-by: Jerin Jacob <jerinj@marvell.com> ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 4/8] trace: avoid confusion on optarg 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand ` (2 preceding siblings ...) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 3/8] trace: simplify trace point headers David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 7:55 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 5/8] trace: remove unneeded checks in internal API David Marchand ` (4 subsequent siblings) 8 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev; +Cc: thomas, Jerin Jacob, Sunil Kumar Kori Prefer a local name to optarg which is a global symbol from the C library. Fixes: 8c8066ea6a7b ("trace: add trace mode configuration parameter") Signed-off-by: David Marchand <david.marchand@redhat.com> --- .../common/eal_common_trace_utils.c | 32 +++++++++---------- lib/librte_eal/common/eal_trace.h | 8 ++--- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/lib/librte_eal/common/eal_common_trace_utils.c b/lib/librte_eal/common/eal_common_trace_utils.c index fce8892c38..a7c5893b00 100644 --- a/lib/librte_eal/common/eal_common_trace_utils.c +++ b/lib/librte_eal/common/eal_common_trace_utils.c @@ -135,7 +135,7 @@ trace_dir_update(const char *str) } int -eal_trace_args_save(const char *optarg) +eal_trace_args_save(const char *val) { struct trace *trace = trace_obj_get(); char *trace_args; @@ -144,17 +144,17 @@ eal_trace_args_save(const char *optarg) nb_args = trace->args.nb_args; if (nb_args >= TRACE_MAX_ARGS) { - trace_err("ignoring trace %s as limit exceeds", optarg); + trace_err("ignoring trace %s as limit exceeds", val); return 0; } - trace_args = calloc(1, (strlen(optarg) + 1)); + trace_args = calloc(1, (strlen(val) + 1)); if (trace_args == NULL) { - trace_err("fail to allocate memory for %s", optarg); + trace_err("fail to allocate memory for %s", val); return -ENOMEM; } - memcpy(trace_args, optarg, strlen(optarg)); + memcpy(trace_args, val, strlen(val)); trace->args.args[nb_args++] = trace_args; trace->args.nb_args = nb_args; return 0; @@ -194,17 +194,17 @@ trace_args_apply(const char *arg) } int -eal_trace_bufsz_args_save(char const *optarg) +eal_trace_bufsz_args_save(char const *val) { struct trace *trace = trace_obj_get(); uint64_t bufsz; - if (optarg == NULL) { + if (val == NULL) { trace_err("no optarg is passed"); return -EINVAL; } - bufsz = rte_str_to_size(optarg); + bufsz = rte_str_to_size(val); if (bufsz == 0) { trace_err("buffer size cannot be zero"); return -EINVAL; @@ -224,14 +224,14 @@ trace_bufsz_args_apply(void) } int -eal_trace_mode_args_save(const char *optarg) +eal_trace_mode_args_save(const char *val) { struct trace *trace = trace_obj_get(); - size_t len = strlen(optarg); + size_t len = strlen(val); unsigned long tmp; char *pattern; - if (optarg == NULL) { + if (val == NULL) { trace_err("no optarg is passed"); return -EINVAL; } @@ -247,7 +247,7 @@ eal_trace_mode_args_save(const char *optarg) return -ENOMEM; } - sprintf(pattern, "%s*", optarg); + sprintf(pattern, "%s*", val); if (fnmatch(pattern, "overwrite", 0) == 0) tmp = RTE_TRACE_MODE_OVERWRITE; @@ -264,19 +264,19 @@ eal_trace_mode_args_save(const char *optarg) } int -eal_trace_dir_args_save(char const *optarg) +eal_trace_dir_args_save(char const *val) { struct trace *trace = trace_obj_get(); uint32_t size = sizeof(trace->dir); char *dir_path = NULL; int rc; - if (optarg == NULL) { + if (val == NULL) { trace_err("no optarg is passed"); return -EINVAL; } - if (strlen(optarg) >= size) { + if (strlen(val) >= size) { trace_err("input string is too big"); return -ENAMETOOLONG; } @@ -287,7 +287,7 @@ eal_trace_dir_args_save(char const *optarg) return -ENOMEM; } - sprintf(dir_path, "%s/", optarg); + sprintf(dir_path, "%s/", val); rc = trace_dir_update(dir_path); free(dir_path); diff --git a/lib/librte_eal/common/eal_trace.h b/lib/librte_eal/common/eal_trace.h index f53ccc0d50..7d95bd2aa9 100644 --- a/lib/librte_eal/common/eal_trace.h +++ b/lib/librte_eal/common/eal_trace.h @@ -111,10 +111,10 @@ void trace_mem_per_thread_free(void); /* EAL interface */ int eal_trace_init(void); void eal_trace_fini(void); -int eal_trace_args_save(const char *optarg); +int eal_trace_args_save(const char *val); void eal_trace_args_free(void); -int eal_trace_dir_args_save(const char *optarg); -int eal_trace_mode_args_save(const char *optarg); -int eal_trace_bufsz_args_save(const char *optarg); +int eal_trace_dir_args_save(const char *val); +int eal_trace_mode_args_save(const char *val); +int eal_trace_bufsz_args_save(const char *val); #endif /* __EAL_TRACE_H */ -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 4/8] trace: avoid confusion on optarg 2020-05-03 20:31 ` [dpdk-dev] [PATCH 4/8] trace: avoid confusion on optarg David Marchand @ 2020-05-04 7:55 ` Sunil Kumar Kori 2020-05-04 14:09 ` David Marchand 0 siblings, 1 reply; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-04 7:55 UTC (permalink / raw) To: David Marchand, dev; +Cc: thomas, Jerin Jacob Kollanukkaran Overall, it looks okay but I think "args" will be more relevant as each API says XXX_args_save(). What do you say ? Regards Sunil Kumar Kori >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 2:02 AM >To: dev@dpdk.org >Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; >Sunil Kumar Kori <skori@marvell.com> >Subject: [EXT] [PATCH 4/8] trace: avoid confusion on optarg > >External Email > >---------------------------------------------------------------------- >Prefer a local name to optarg which is a global symbol from the C library. > >Fixes: 8c8066ea6a7b ("trace: add trace mode configuration parameter") > >Signed-off-by: David Marchand <david.marchand@redhat.com> >--- > .../common/eal_common_trace_utils.c | 32 +++++++++---------- > lib/librte_eal/common/eal_trace.h | 8 ++--- > 2 files changed, 20 insertions(+), 20 deletions(-) > >diff --git a/lib/librte_eal/common/eal_common_trace_utils.c >b/lib/librte_eal/common/eal_common_trace_utils.c >index fce8892c38..a7c5893b00 100644 >--- a/lib/librte_eal/common/eal_common_trace_utils.c >+++ b/lib/librte_eal/common/eal_common_trace_utils.c >@@ -135,7 +135,7 @@ trace_dir_update(const char *str) } > > int >-eal_trace_args_save(const char *optarg) >+eal_trace_args_save(const char *val) > { > struct trace *trace = trace_obj_get(); > char *trace_args; >@@ -144,17 +144,17 @@ eal_trace_args_save(const char *optarg) > nb_args = trace->args.nb_args; > > if (nb_args >= TRACE_MAX_ARGS) { >- trace_err("ignoring trace %s as limit exceeds", optarg); >+ trace_err("ignoring trace %s as limit exceeds", val); > return 0; > } > >- trace_args = calloc(1, (strlen(optarg) + 1)); >+ trace_args = calloc(1, (strlen(val) + 1)); > if (trace_args == NULL) { >- trace_err("fail to allocate memory for %s", optarg); >+ trace_err("fail to allocate memory for %s", val); > return -ENOMEM; > } > >- memcpy(trace_args, optarg, strlen(optarg)); >+ memcpy(trace_args, val, strlen(val)); > trace->args.args[nb_args++] = trace_args; > trace->args.nb_args = nb_args; > return 0; [snip] >2.23.0 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 4/8] trace: avoid confusion on optarg 2020-05-04 7:55 ` [dpdk-dev] [EXT] " Sunil Kumar Kori @ 2020-05-04 14:09 ` David Marchand 2020-05-05 5:45 ` Sunil Kumar Kori 0 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-04 14:09 UTC (permalink / raw) To: Sunil Kumar Kori; +Cc: dev, thomas, Jerin Jacob Kollanukkaran On Mon, May 4, 2020 at 9:55 AM Sunil Kumar Kori <skori@marvell.com> wrote: > > Overall, it looks okay but I think "args" will be more relevant as each API says XXX_args_save(). > What do you say ? No opinion, the function name itself indicates we are dealing with arguments. I can go with args if you like. -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 4/8] trace: avoid confusion on optarg 2020-05-04 14:09 ` David Marchand @ 2020-05-05 5:45 ` Sunil Kumar Kori 2020-05-05 5:47 ` Sunil Kumar Kori 0 siblings, 1 reply; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-05 5:45 UTC (permalink / raw) To: David Marchand; +Cc: dev, thomas, Jerin Jacob Kollanukkaran >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 7:39 PM >To: Sunil Kumar Kori <skori@marvell.com> >Cc: dev@dpdk.org; thomas@monjalon.net; Jerin Jacob Kollanukkaran ><jerinj@marvell.com> >Subject: Re: [EXT] [PATCH 4/8] trace: avoid confusion on optarg > >On Mon, May 4, 2020 at 9:55 AM Sunil Kumar Kori <skori@marvell.com> >wrote: >> >> Overall, it looks okay but I think "args" will be more relevant as each API says >XXX_args_save(). >> What do you say ? > >No opinion, the function name itself indicates we are dealing with arguments. >I can go with args if you like. No problem. Let it be as it is. > > >-- >David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 4/8] trace: avoid confusion on optarg 2020-05-05 5:45 ` Sunil Kumar Kori @ 2020-05-05 5:47 ` Sunil Kumar Kori 0 siblings, 0 replies; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-05 5:47 UTC (permalink / raw) To: David Marchand; +Cc: dev, thomas, Jerin Jacob Kollanukkaran >-----Original Message----- >From: Sunil Kumar Kori >Sent: Tuesday, May 5, 2020 11:15 AM >To: David Marchand <david.marchand@redhat.com> >Cc: dev@dpdk.org; thomas@monjalon.net; Jerin Jacob Kollanukkaran ><jerinj@marvell.com> >Subject: RE: [EXT] [PATCH 4/8] trace: avoid confusion on optarg > >>-----Original Message----- >>From: David Marchand <david.marchand@redhat.com> >>Sent: Monday, May 4, 2020 7:39 PM >>To: Sunil Kumar Kori <skori@marvell.com> >>Cc: dev@dpdk.org; thomas@monjalon.net; Jerin Jacob Kollanukkaran >><jerinj@marvell.com> >>Subject: Re: [EXT] [PATCH 4/8] trace: avoid confusion on optarg >> >>On Mon, May 4, 2020 at 9:55 AM Sunil Kumar Kori <skori@marvell.com> >>wrote: >>> >>> Overall, it looks okay but I think "args" will be more relevant as >>> each API says >>XXX_args_save(). >>> What do you say ? >> >>No opinion, the function name itself indicates we are dealing with >arguments. >>I can go with args if you like. >No problem. Let it be as it is. > Acked-by: Sunil Kumar Kori <skori@mavell.com> >> >> >>-- >>David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 5/8] trace: remove unneeded checks in internal API 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand ` (3 preceding siblings ...) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 4/8] trace: avoid confusion on optarg David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 8:16 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 6/8] trace: remove limitation on patterns number David Marchand ` (3 subsequent siblings) 8 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev; +Cc: thomas, Jerin Jacob, Sunil Kumar Kori The trace framework can be configured via 4 EAL options: - --trace which calls eal_trace_args_save, - --trace-dir which calls eal_trace_dir_args_save, - --trace-bufsz which calls eal_trace_bufsz_args_save, - --trace-mode which calls eal_trace_mode_args_save. Those 4 internal callbacks are getting passed a non NULL value: optarg won't be NULL since those options are declared with required_argument (man getopt_long). eal_trace_bufsz_args_save() already trusted passed value, align the other 3 internal callbacks. Coverity issue: 357768 Fixes: 8c8066ea6a7b ("trace: add trace mode configuration parameter") Signed-off-by: David Marchand <david.marchand@redhat.com> --- lib/librte_eal/common/eal_common_trace_utils.c | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/lib/librte_eal/common/eal_common_trace_utils.c b/lib/librte_eal/common/eal_common_trace_utils.c index a7c5893b00..4077acf428 100644 --- a/lib/librte_eal/common/eal_common_trace_utils.c +++ b/lib/librte_eal/common/eal_common_trace_utils.c @@ -199,11 +199,6 @@ eal_trace_bufsz_args_save(char const *val) struct trace *trace = trace_obj_get(); uint64_t bufsz; - if (val == NULL) { - trace_err("no optarg is passed"); - return -EINVAL; - } - bufsz = rte_str_to_size(val); if (bufsz == 0) { trace_err("buffer size cannot be zero"); @@ -231,11 +226,6 @@ eal_trace_mode_args_save(const char *val) unsigned long tmp; char *pattern; - if (val == NULL) { - trace_err("no optarg is passed"); - return -EINVAL; - } - if (len == 0) { trace_err("value is not provided with option"); return -EINVAL; @@ -271,11 +261,6 @@ eal_trace_dir_args_save(char const *val) char *dir_path = NULL; int rc; - if (val == NULL) { - trace_err("no optarg is passed"); - return -EINVAL; - } - if (strlen(val) >= size) { trace_err("input string is too big"); return -ENAMETOOLONG; -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 5/8] trace: remove unneeded checks in internal API 2020-05-03 20:31 ` [dpdk-dev] [PATCH 5/8] trace: remove unneeded checks in internal API David Marchand @ 2020-05-04 8:16 ` Sunil Kumar Kori 0 siblings, 0 replies; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-04 8:16 UTC (permalink / raw) To: David Marchand, dev; +Cc: thomas, Jerin Jacob Kollanukkaran >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 2:02 AM >To: dev@dpdk.org >Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; >Sunil Kumar Kori <skori@marvell.com> >Subject: [EXT] [PATCH 5/8] trace: remove unneeded checks in internal API > >External Email > >---------------------------------------------------------------------- >The trace framework can be configured via 4 EAL options: >- --trace which calls eal_trace_args_save, >- --trace-dir which calls eal_trace_dir_args_save, >- --trace-bufsz which calls eal_trace_bufsz_args_save, >- --trace-mode which calls eal_trace_mode_args_save. > >Those 4 internal callbacks are getting passed a non NULL value: >optarg won't be NULL since those options are declared with >required_argument (man getopt_long). > >eal_trace_bufsz_args_save() already trusted passed value, align the other >3 internal callbacks. > >Coverity issue: 357768 >Fixes: 8c8066ea6a7b ("trace: add trace mode configuration parameter") > >Signed-off-by: David Marchand <david.marchand@redhat.com> >--- Acked-by: Sunil Kumar Kori <skori@mavell.com> [snip] ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 6/8] trace: remove limitation on patterns number 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand ` (4 preceding siblings ...) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 5/8] trace: remove unneeded checks in internal API David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 8:48 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 7/8] trace: remove string duplication David Marchand ` (2 subsequent siblings) 8 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev; +Cc: thomas, Jerin Jacob, Sunil Kumar Kori There is nothing performance sensitive in this list, use dynamic allocations and remove the arbitrary limit on the number of trace patterns a user can pass. Signed-off-by: David Marchand <david.marchand@redhat.com> --- lib/librte_eal/common/eal_common_trace.c | 10 +++--- .../common/eal_common_trace_utils.c | 33 ++++++++----------- lib/librte_eal/common/eal_trace.h | 8 ++--- 3 files changed, 23 insertions(+), 28 deletions(-) diff --git a/lib/librte_eal/common/eal_common_trace.c b/lib/librte_eal/common/eal_common_trace.c index 5a365c61da..875553d7e5 100644 --- a/lib/librte_eal/common/eal_common_trace.c +++ b/lib/librte_eal/common/eal_common_trace.c @@ -21,7 +21,7 @@ static RTE_DEFINE_PER_LCORE(char, ctf_field[TRACE_CTF_FIELD_SIZE]); static RTE_DEFINE_PER_LCORE(int, ctf_count); static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); -static struct trace trace; +static struct trace trace = { .args = STAILQ_HEAD_INITIALIZER(trace.args), }; struct trace * trace_obj_get(void) @@ -38,7 +38,7 @@ trace_list_head_get(void) int eal_trace_init(void) { - uint8_t i; + struct trace_arg *arg; /* Trace memory should start with 8B aligned for natural alignment */ RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) != 0); @@ -49,7 +49,7 @@ eal_trace_init(void) goto fail; } - if (trace.args.nb_args) + if (!STAILQ_EMPTY(&trace.args)) trace.status = true; if (!rte_trace_is_enabled()) @@ -82,8 +82,8 @@ eal_trace_init(void) goto fail; /* Apply global configurations */ - for (i = 0; i < trace.args.nb_args; i++) - trace_args_apply(trace.args.args[i]); + STAILQ_FOREACH(arg, &trace.args, next) + trace_args_apply(arg->val); rte_trace_mode_set(trace.mode); diff --git a/lib/librte_eal/common/eal_common_trace_utils.c b/lib/librte_eal/common/eal_common_trace_utils.c index 4077acf428..15384ce4f1 100644 --- a/lib/librte_eal/common/eal_common_trace_utils.c +++ b/lib/librte_eal/common/eal_common_trace_utils.c @@ -138,25 +138,20 @@ int eal_trace_args_save(const char *val) { struct trace *trace = trace_obj_get(); - char *trace_args; - uint8_t nb_args; + struct trace_arg *arg = malloc(sizeof(*arg)); - nb_args = trace->args.nb_args; - - if (nb_args >= TRACE_MAX_ARGS) { - trace_err("ignoring trace %s as limit exceeds", val); - return 0; + if (arg == NULL) { + trace_err("failed to allocate memory for %s", val); + return -ENOMEM; } - trace_args = calloc(1, (strlen(val) + 1)); - if (trace_args == NULL) { - trace_err("fail to allocate memory for %s", val); + arg->val = strdup(val); + if (arg->val == NULL) { + trace_err("failed to allocate memory for %s", val); return -ENOMEM; } - memcpy(trace_args, val, strlen(val)); - trace->args.args[nb_args++] = trace_args; - trace->args.nb_args = nb_args; + STAILQ_INSERT_TAIL(&trace->args, arg, next); return 0; } @@ -164,13 +159,13 @@ void eal_trace_args_free(void) { struct trace *trace = trace_obj_get(); - int i; + struct trace_arg *arg; - for (i = 0; i < trace->args.nb_args; i++) { - if (trace->args.args[i]) { - free((void *)trace->args.args[i]); - trace->args.args[i] = NULL; - } + while (!STAILQ_EMPTY(&trace->args)) { + arg = STAILQ_FIRST(&trace->args); + STAILQ_REMOVE_HEAD(&trace->args, next); + free(arg->val); + free(arg); } } diff --git a/lib/librte_eal/common/eal_trace.h b/lib/librte_eal/common/eal_trace.h index 7d95bd2aa9..943b5ecbc5 100644 --- a/lib/librte_eal/common/eal_trace.h +++ b/lib/librte_eal/common/eal_trace.h @@ -46,9 +46,9 @@ struct thread_mem_meta { enum trace_area_e area; }; -struct trace_args { - uint8_t nb_args; - char *args[TRACE_MAX_ARGS]; +struct trace_arg { + STAILQ_ENTRY(trace_arg) next; + char *val; }; struct trace { @@ -59,7 +59,7 @@ struct trace { enum rte_trace_mode mode; rte_uuid_t uuid; uint32_t buff_len; - struct trace_args args; + STAILQ_HEAD(trace_arg_head, trace_arg) args; uint32_t nb_trace_points; uint32_t nb_trace_mem_list; struct thread_mem_meta *lcore_meta; -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 6/8] trace: remove limitation on patterns number 2020-05-03 20:31 ` [dpdk-dev] [PATCH 6/8] trace: remove limitation on patterns number David Marchand @ 2020-05-04 8:48 ` Sunil Kumar Kori 2020-05-04 14:14 ` David Marchand 0 siblings, 1 reply; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-04 8:48 UTC (permalink / raw) To: David Marchand, dev; +Cc: thomas, Jerin Jacob Kollanukkaran >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 2:02 AM >To: dev@dpdk.org >Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; >Sunil Kumar Kori <skori@marvell.com> >Subject: [EXT] [PATCH 6/8] trace: remove limitation on patterns number > >External Email > >---------------------------------------------------------------------- >There is nothing performance sensitive in this list, use dynamic allocations and >remove the arbitrary limit on the number of trace patterns a user can pass. > >Signed-off-by: David Marchand <david.marchand@redhat.com> >--- > lib/librte_eal/common/eal_common_trace.c | 10 +++--- > .../common/eal_common_trace_utils.c | 33 ++++++++----------- > lib/librte_eal/common/eal_trace.h | 8 ++--- > 3 files changed, 23 insertions(+), 28 deletions(-) > >diff --git a/lib/librte_eal/common/eal_common_trace.c >b/lib/librte_eal/common/eal_common_trace.c >index 5a365c61da..875553d7e5 100644 >--- a/lib/librte_eal/common/eal_common_trace.c >+++ b/lib/librte_eal/common/eal_common_trace.c >@@ -21,7 +21,7 @@ static RTE_DEFINE_PER_LCORE(char, >ctf_field[TRACE_CTF_FIELD_SIZE]); static RTE_DEFINE_PER_LCORE(int, >ctf_count); > > static struct trace_point_head tp_list = STAILQ_HEAD_INITIALIZER(tp_list); - >static struct trace trace; >+static struct trace trace = { .args = >+STAILQ_HEAD_INITIALIZER(trace.args), }; > > struct trace * > trace_obj_get(void) >@@ -38,7 +38,7 @@ trace_list_head_get(void) int > eal_trace_init(void) > { >- uint8_t i; >+ struct trace_arg *arg; > > /* Trace memory should start with 8B aligned for natural alignment */ > RTE_BUILD_BUG_ON((offsetof(struct __rte_trace_header, mem) % 8) >!= 0); @@ -49,7 +49,7 @@ eal_trace_init(void) > goto fail; > } > >- if (trace.args.nb_args) >+ if (!STAILQ_EMPTY(&trace.args)) > trace.status = true; > > if (!rte_trace_is_enabled()) >@@ -82,8 +82,8 @@ eal_trace_init(void) > goto fail; > > /* Apply global configurations */ >- for (i = 0; i < trace.args.nb_args; i++) >- trace_args_apply(trace.args.args[i]); >+ STAILQ_FOREACH(arg, &trace.args, next) >+ trace_args_apply(arg->val); > > rte_trace_mode_set(trace.mode); > >diff --git a/lib/librte_eal/common/eal_common_trace_utils.c >b/lib/librte_eal/common/eal_common_trace_utils.c >index 4077acf428..15384ce4f1 100644 >--- a/lib/librte_eal/common/eal_common_trace_utils.c >+++ b/lib/librte_eal/common/eal_common_trace_utils.c >@@ -138,25 +138,20 @@ int > eal_trace_args_save(const char *val) > { > struct trace *trace = trace_obj_get(); >- char *trace_args; >- uint8_t nb_args; >+ struct trace_arg *arg = malloc(sizeof(*arg)); Won't "malloc(sizeof(struct trace_arg))" be more readable ? > >- nb_args = trace->args.nb_args; >- >- if (nb_args >= TRACE_MAX_ARGS) { >- trace_err("ignoring trace %s as limit exceeds", val); >- return 0; >+ if (arg == NULL) { >+ trace_err("failed to allocate memory for %s", val); >+ return -ENOMEM; > } > >- trace_args = calloc(1, (strlen(val) + 1)); >- if (trace_args == NULL) { >- trace_err("fail to allocate memory for %s", val); >+ arg->val = strdup(val); >+ if (arg->val == NULL) { >+ trace_err("failed to allocate memory for %s", val); "arg" needs to be freed here. > return -ENOMEM; > } > >- memcpy(trace_args, val, strlen(val)); >- trace->args.args[nb_args++] = trace_args; >- trace->args.nb_args = nb_args; >+ STAILQ_INSERT_TAIL(&trace->args, arg, next); > return 0; > } > >@@ -164,13 +159,13 @@ void > eal_trace_args_free(void) > { > struct trace *trace = trace_obj_get(); >- int i; >+ struct trace_arg *arg; > >- for (i = 0; i < trace->args.nb_args; i++) { >- if (trace->args.args[i]) { >- free((void *)trace->args.args[i]); >- trace->args.args[i] = NULL; >- } >+ while (!STAILQ_EMPTY(&trace->args)) { >+ arg = STAILQ_FIRST(&trace->args); >+ STAILQ_REMOVE_HEAD(&trace->args, next); >+ free(arg->val); >+ free(arg); > } > } > >diff --git a/lib/librte_eal/common/eal_trace.h >b/lib/librte_eal/common/eal_trace.h >index 7d95bd2aa9..943b5ecbc5 100644 >--- a/lib/librte_eal/common/eal_trace.h >+++ b/lib/librte_eal/common/eal_trace.h >@@ -46,9 +46,9 @@ struct thread_mem_meta { > enum trace_area_e area; > }; > >-struct trace_args { >- uint8_t nb_args; >- char *args[TRACE_MAX_ARGS]; >+struct trace_arg { >+ STAILQ_ENTRY(trace_arg) next; >+ char *val; > }; > > struct trace { >@@ -59,7 +59,7 @@ struct trace { > enum rte_trace_mode mode; > rte_uuid_t uuid; > uint32_t buff_len; >- struct trace_args args; >+ STAILQ_HEAD(trace_arg_head, trace_arg) args; "trace_arg_head" is not required. It can be removed. > uint32_t nb_trace_points; > uint32_t nb_trace_mem_list; > struct thread_mem_meta *lcore_meta; >-- >2.23.0 ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 6/8] trace: remove limitation on patterns number 2020-05-04 8:48 ` [dpdk-dev] [EXT] " Sunil Kumar Kori @ 2020-05-04 14:14 ` David Marchand 2020-05-05 5:54 ` Sunil Kumar Kori 0 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-04 14:14 UTC (permalink / raw) To: Sunil Kumar Kori; +Cc: dev, thomas, Jerin Jacob Kollanukkaran On Mon, May 4, 2020 at 10:48 AM Sunil Kumar Kori <skori@marvell.com> wrote: > >diff --git a/lib/librte_eal/common/eal_common_trace_utils.c > >b/lib/librte_eal/common/eal_common_trace_utils.c > >index 4077acf428..15384ce4f1 100644 > >--- a/lib/librte_eal/common/eal_common_trace_utils.c > >+++ b/lib/librte_eal/common/eal_common_trace_utils.c > >@@ -138,25 +138,20 @@ int > > eal_trace_args_save(const char *val) > > { > > struct trace *trace = trace_obj_get(); > >- char *trace_args; > >- uint8_t nb_args; > >+ struct trace_arg *arg = malloc(sizeof(*arg)); > Won't "malloc(sizeof(struct trace_arg))" be more readable ? ptr = malloc(sizeof(*ptr)); is more common in EAL code. I prefer this form. > > > > >- nb_args = trace->args.nb_args; > >- > >- if (nb_args >= TRACE_MAX_ARGS) { > >- trace_err("ignoring trace %s as limit exceeds", val); > >- return 0; > >+ if (arg == NULL) { > >+ trace_err("failed to allocate memory for %s", val); > >+ return -ENOMEM; > > } > > > >- trace_args = calloc(1, (strlen(val) + 1)); > >- if (trace_args == NULL) { > >- trace_err("fail to allocate memory for %s", val); > >+ arg->val = strdup(val); > >+ if (arg->val == NULL) { > >+ trace_err("failed to allocate memory for %s", val); > "arg" needs to be freed here. argh, indeed. > > > return -ENOMEM; > > } > > > >- memcpy(trace_args, val, strlen(val)); > >- trace->args.args[nb_args++] = trace_args; > >- trace->args.nb_args = nb_args; > >+ STAILQ_INSERT_TAIL(&trace->args, arg, next); > > return 0; > > } > > > >diff --git a/lib/librte_eal/common/eal_trace.h > >b/lib/librte_eal/common/eal_trace.h > >index 7d95bd2aa9..943b5ecbc5 100644 > >--- a/lib/librte_eal/common/eal_trace.h > >+++ b/lib/librte_eal/common/eal_trace.h > >@@ -46,9 +46,9 @@ struct thread_mem_meta { > > enum trace_area_e area; > > }; > > > >-struct trace_args { > >- uint8_t nb_args; > >- char *args[TRACE_MAX_ARGS]; > >+struct trace_arg { > >+ STAILQ_ENTRY(trace_arg) next; > >+ char *val; > > }; > > > > struct trace { > >@@ -59,7 +59,7 @@ struct trace { > > enum rte_trace_mode mode; > > rte_uuid_t uuid; > > uint32_t buff_len; > >- struct trace_args args; > >+ STAILQ_HEAD(trace_arg_head, trace_arg) args; > "trace_arg_head" is not required. It can be removed. Ack. > > > uint32_t nb_trace_points; > > uint32_t nb_trace_mem_list; > > struct thread_mem_meta *lcore_meta; > >-- > >2.23.0 > -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 6/8] trace: remove limitation on patterns number 2020-05-04 14:14 ` David Marchand @ 2020-05-05 5:54 ` Sunil Kumar Kori 0 siblings, 0 replies; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-05 5:54 UTC (permalink / raw) To: David Marchand; +Cc: dev, thomas, Jerin Jacob Kollanukkaran >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 7:44 PM >To: Sunil Kumar Kori <skori@marvell.com> >Cc: dev@dpdk.org; thomas@monjalon.net; Jerin Jacob Kollanukkaran ><jerinj@marvell.com> >Subject: Re: [EXT] [PATCH 6/8] trace: remove limitation on patterns number > >On Mon, May 4, 2020 at 10:48 AM Sunil Kumar Kori <skori@marvell.com> >wrote: >> >diff --git a/lib/librte_eal/common/eal_common_trace_utils.c >> >b/lib/librte_eal/common/eal_common_trace_utils.c >> >index 4077acf428..15384ce4f1 100644 >> >--- a/lib/librte_eal/common/eal_common_trace_utils.c >> >+++ b/lib/librte_eal/common/eal_common_trace_utils.c >> >@@ -138,25 +138,20 @@ int >> > eal_trace_args_save(const char *val) { >> > struct trace *trace = trace_obj_get(); >> >- char *trace_args; >> >- uint8_t nb_args; >> >+ struct trace_arg *arg = malloc(sizeof(*arg)); >> Won't "malloc(sizeof(struct trace_arg))" be more readable ? > >ptr = malloc(sizeof(*ptr)); is more common in EAL code. >I prefer this form. > > Ack >> >> > >> >- nb_args = trace->args.nb_args; >> >- >> >- if (nb_args >= TRACE_MAX_ARGS) { >> >- trace_err("ignoring trace %s as limit exceeds", val); >> >- return 0; >> >+ if (arg == NULL) { >> >+ trace_err("failed to allocate memory for %s", val); >> >+ return -ENOMEM; >> > } >> > >> >- trace_args = calloc(1, (strlen(val) + 1)); >> >- if (trace_args == NULL) { >> >- trace_err("fail to allocate memory for %s", val); >> >+ arg->val = strdup(val); >> >+ if (arg->val == NULL) { >> >+ trace_err("failed to allocate memory for %s", val); >> "arg" needs to be freed here. > >argh, indeed. > > Sorry, I didn't understand "argh" but assuming that you are agreed. >> >> > return -ENOMEM; >> > } >> > >> >- memcpy(trace_args, val, strlen(val)); >> >- trace->args.args[nb_args++] = trace_args; >> >- trace->args.nb_args = nb_args; >> >+ STAILQ_INSERT_TAIL(&trace->args, arg, next); >> > return 0; >> > } >> > > >> >diff --git a/lib/librte_eal/common/eal_trace.h >> >b/lib/librte_eal/common/eal_trace.h >> >index 7d95bd2aa9..943b5ecbc5 100644 >> >--- a/lib/librte_eal/common/eal_trace.h >> >+++ b/lib/librte_eal/common/eal_trace.h >> >@@ -46,9 +46,9 @@ struct thread_mem_meta { >> > enum trace_area_e area; >> > }; >> > >> >-struct trace_args { >> >- uint8_t nb_args; >> >- char *args[TRACE_MAX_ARGS]; >> >+struct trace_arg { >> >+ STAILQ_ENTRY(trace_arg) next; >> >+ char *val; >> > }; >> > >> > struct trace { >> >@@ -59,7 +59,7 @@ struct trace { >> > enum rte_trace_mode mode; >> > rte_uuid_t uuid; >> > uint32_t buff_len; >> >- struct trace_args args; >> >+ STAILQ_HEAD(trace_arg_head, trace_arg) args; >> "trace_arg_head" is not required. It can be removed. > >Ack. > > >> >> > uint32_t nb_trace_points; >> > uint32_t nb_trace_mem_list; >> > struct thread_mem_meta *lcore_meta; >> >-- >> >2.23.0 >> > > >-- >David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 7/8] trace: remove string duplication 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand ` (5 preceding siblings ...) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 6/8] trace: remove limitation on patterns number David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-04 9:01 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 8/8] trace: fix build with gcc 10 David Marchand 2020-05-06 13:06 ` [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand 8 siblings, 1 reply; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev; +Cc: thomas, Jerin Jacob, Sunil Kumar Kori No need to duplicate an untouched string. Signed-off-by: David Marchand <david.marchand@redhat.com> --- lib/librte_eal/common/eal_common_trace_utils.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/lib/librte_eal/common/eal_common_trace_utils.c b/lib/librte_eal/common/eal_common_trace_utils.c index 15384ce4f1..49cc8d7b1d 100644 --- a/lib/librte_eal/common/eal_common_trace_utils.c +++ b/lib/librte_eal/common/eal_common_trace_utils.c @@ -172,19 +172,11 @@ eal_trace_args_free(void) int trace_args_apply(const char *arg) { - char *str; - - str = strdup(arg); - if (str == NULL) - return -1; - - if (rte_trace_regexp(str, true) < 0) { - trace_err("cannot enable trace for %s", str); - free(str); + if (rte_trace_regexp(arg, true) < 0) { + trace_err("cannot enable trace for %s", arg); return -1; } - free(str); return 0; } -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [EXT] [PATCH 7/8] trace: remove string duplication 2020-05-03 20:31 ` [dpdk-dev] [PATCH 7/8] trace: remove string duplication David Marchand @ 2020-05-04 9:01 ` Sunil Kumar Kori 0 siblings, 0 replies; 55+ messages in thread From: Sunil Kumar Kori @ 2020-05-04 9:01 UTC (permalink / raw) To: David Marchand, dev; +Cc: thomas, Jerin Jacob Kollanukkaran >-----Original Message----- >From: David Marchand <david.marchand@redhat.com> >Sent: Monday, May 4, 2020 2:02 AM >To: dev@dpdk.org >Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; >Sunil Kumar Kori <skori@marvell.com> >Subject: [EXT] [PATCH 7/8] trace: remove string duplication > >External Email > >---------------------------------------------------------------------- >No need to duplicate an untouched string. > >Signed-off-by: David Marchand <david.marchand@redhat.com> >--- > lib/librte_eal/common/eal_common_trace_utils.c | 12 ++---------- > 1 file changed, 2 insertions(+), 10 deletions(-) > >diff --git a/lib/librte_eal/common/eal_common_trace_utils.c >b/lib/librte_eal/common/eal_common_trace_utils.c >index 15384ce4f1..49cc8d7b1d 100644 >--- a/lib/librte_eal/common/eal_common_trace_utils.c >+++ b/lib/librte_eal/common/eal_common_trace_utils.c >@@ -172,19 +172,11 @@ eal_trace_args_free(void) int >trace_args_apply(const char *arg) { >- char *str; >- >- str = strdup(arg); >- if (str == NULL) >- return -1; >- >- if (rte_trace_regexp(str, true) < 0) { >- trace_err("cannot enable trace for %s", str); >- free(str); >+ if (rte_trace_regexp(arg, true) < 0) { >+ trace_err("cannot enable trace for %s", arg); > return -1; > } > >- free(str); > return 0; > } > >-- Acked-by: Sunil Kumar Kori <skori@mavell.com> >2.23.0 ^ permalink raw reply [flat|nested] 55+ messages in thread
* [dpdk-dev] [PATCH 8/8] trace: fix build with gcc 10 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand ` (6 preceding siblings ...) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 7/8] trace: remove string duplication David Marchand @ 2020-05-03 20:31 ` David Marchand 2020-05-06 13:06 ` [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand 8 siblings, 0 replies; 55+ messages in thread From: David Marchand @ 2020-05-03 20:31 UTC (permalink / raw) To: dev; +Cc: thomas, Phil Yang, Lijian Zhang, Sunil Kumar Kori, Jerin Jacob From: Phil Yang <phil.yang@arm.com> Prevent from writing beyond the allocated memory. GCC 10 compiling output: eal_common_trace_utils.c: In function 'eal_trace_dir_args_save': eal_common_trace_utils.c:290:24: error: '__builtin___sprintf_chk' \ may write a terminating nul past the end of the destination \ [-Werror=format-overflow=] 290 | sprintf(dir_path, "%s/", optarg); | ^ Fixes: 8af866df8d8c ("trace: add trace directory configuration parameter") Signed-off-by: Phil Yang <phil.yang@arm.com> Reviewed-by: Lijian Zhang <lijian.zhang@arm.com> Tested-by: Lijian Zhang <lijian.zhang@arm.com> Acked-by: Sunil Kumar Kori <skori@marvell.com> Signed-off-by: David Marchand <david.marchand@redhat.com> --- Changes since Phil patch: - removed single-use 'size' variable, - removed comment on PATH_MAX (this comment will get obsolete if trace->dir definition changes), - asprintf return code is not used, no need to store, --- lib/librte_eal/common/eal_common_trace_utils.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/lib/librte_eal/common/eal_common_trace_utils.c b/lib/librte_eal/common/eal_common_trace_utils.c index 49cc8d7b1d..988d7593e1 100644 --- a/lib/librte_eal/common/eal_common_trace_utils.c +++ b/lib/librte_eal/common/eal_common_trace_utils.c @@ -244,22 +244,19 @@ int eal_trace_dir_args_save(char const *val) { struct trace *trace = trace_obj_get(); - uint32_t size = sizeof(trace->dir); - char *dir_path = NULL; + char *dir_path; int rc; - if (strlen(val) >= size) { + if (strlen(val) >= sizeof(trace->dir) - 1) { trace_err("input string is too big"); return -ENAMETOOLONG; } - dir_path = (char *)calloc(1, size); - if (dir_path == NULL) { - trace_err("fail to allocate memory"); + if (asprintf(&dir_path, "%s/", val) == -1) { + trace_err("failed to copy directory: %s", strerror(errno)); return -ENOMEM; } - sprintf(dir_path, "%s/", val); rc = trace_dir_update(dir_path); free(dir_path); -- 2.23.0 ^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand ` (7 preceding siblings ...) 2020-05-03 20:31 ` [dpdk-dev] [PATCH 8/8] trace: fix build with gcc 10 David Marchand @ 2020-05-06 13:06 ` David Marchand 8 siblings, 0 replies; 55+ messages in thread From: David Marchand @ 2020-05-06 13:06 UTC (permalink / raw) To: dev; +Cc: Thomas Monjalon, Jerin Jacob Kollanukkaran, Sunil Kumar Kori On Sun, May 3, 2020 at 10:32 PM David Marchand <david.marchand@redhat.com> wrote: > > Couple of fixes and cleanup (missed during initial review) on the newly > introduced traces framework. > Phil patch [1] has been rebased as part of this series. > > 1: http://patchwork.dpdk.org/patch/69467/ > > -- > David Marchand > > David Marchand (7): > cryptodev: fix trace points registration > trace: simplify trace point registration > trace: simplify trace point headers > trace: avoid confusion on optarg > trace: remove unneeded checks in internal API > trace: remove limitation on patterns number > trace: remove string duplication Dropped patch 2. Applied changes on other patches, based on reviews from Jerin and Sunil. Series applied. -- David Marchand ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2020-07-05 19:41 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-03 20:31 [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand 2020-05-03 20:31 ` [dpdk-dev] [PATCH 1/8] cryptodev: fix trace points registration David Marchand 2020-05-04 7:41 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration David Marchand 2020-05-04 2:46 ` Jerin Jacob 2020-05-04 14:02 ` Thomas Monjalon 2020-05-04 14:04 ` David Marchand 2020-05-04 14:39 ` Jerin Jacob 2020-05-04 17:08 ` David Marchand 2020-05-04 17:19 ` Jerin Jacob 2020-05-04 17:40 ` David Marchand 2020-05-04 17:54 ` Jerin Jacob 2020-05-04 21:31 ` Thomas Monjalon 2020-05-05 3:43 ` Jerin Jacob 2020-05-05 7:01 ` Thomas Monjalon 2020-05-05 7:17 ` Jerin Jacob 2020-05-05 7:24 ` Thomas Monjalon 2020-05-05 7:33 ` Jerin Jacob 2020-05-05 8:23 ` David Marchand 2020-05-05 10:12 ` Jerin Jacob 2020-05-05 10:26 ` Thomas Monjalon 2020-05-05 10:46 ` Jerin Jacob 2020-05-05 11:48 ` Olivier Matz 2020-05-05 11:35 ` David Marchand 2020-05-05 12:26 ` Jerin Jacob 2020-05-05 15:25 ` Jerin Jacob 2020-05-05 16:28 ` David Marchand 2020-05-05 16:46 ` Jerin Jacob 2020-05-05 16:58 ` Thomas Monjalon 2020-05-05 17:08 ` Jerin Jacob 2020-05-05 17:09 ` Jerin Jacob 2020-05-05 17:20 ` Thomas Monjalon 2020-05-05 17:28 ` Jerin Jacob 2020-05-05 20:10 ` Thomas Monjalon 2020-05-06 6:11 ` Jerin Jacob 2020-07-04 14:31 ` Jerin Jacob 2020-07-04 15:14 ` [dpdk-dev] [PATCH v2] " David Marchand 2020-07-05 19:41 ` Thomas Monjalon 2020-05-03 20:31 ` [dpdk-dev] [PATCH 3/8] trace: simplify trace point headers David Marchand 2020-05-04 6:12 ` Jerin Jacob 2020-05-03 20:31 ` [dpdk-dev] [PATCH 4/8] trace: avoid confusion on optarg David Marchand 2020-05-04 7:55 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-04 14:09 ` David Marchand 2020-05-05 5:45 ` Sunil Kumar Kori 2020-05-05 5:47 ` Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 5/8] trace: remove unneeded checks in internal API David Marchand 2020-05-04 8:16 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 6/8] trace: remove limitation on patterns number David Marchand 2020-05-04 8:48 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-04 14:14 ` David Marchand 2020-05-05 5:54 ` Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 7/8] trace: remove string duplication David Marchand 2020-05-04 9:01 ` [dpdk-dev] [EXT] " Sunil Kumar Kori 2020-05-03 20:31 ` [dpdk-dev] [PATCH 8/8] trace: fix build with gcc 10 David Marchand 2020-05-06 13:06 ` [dpdk-dev] [PATCH 0/8] Traces cleanup for rc2 David Marchand
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.