rte_metrics: move maximum number of metrics into rte_config
diff mbox series

Message ID 20200904223118.10002-1-stephen@networkplumber.org
State New
Delegated to: Thomas Monjalon
Headers show
Series
  • rte_metrics: move maximum number of metrics into rte_config
Related show

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/travis-robot success Travis build: passed
ci/Intel-compilation fail Compilation issues
ci/iol-testing warning Testing issues

Commit Message

Stephen Hemminger Sept. 4, 2020, 10:31 p.m. UTC
If using lots of queues and ports, and having per port or per queue
metrics it is easy to exceed the upper bound of the metric library.
Move the limit into rte_config where user can change it.

Ideally, there would be no upper bound and a dynamic structure
such as red-black tree or hash table would be used for these.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 config/rte_config.h              | 3 +++
 lib/librte_metrics/rte_metrics.h | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

Comments

Stephen Hemminger Sept. 5, 2020, 3:11 a.m. UTC | #1
On Fri,  4 Sep 2020 15:31:19 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

> If using lots of queues and ports, and having per port or per queue
> metrics it is easy to exceed the upper bound of the metric library.
> Move the limit into rte_config where user can change it.
> 
> Ideally, there would be no upper bound and a dynamic structure
> such as red-black tree or hash table would be used for these.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

Note: this version of the patch assumes meson build, it won't work with make based build.

Ignore the CI failures.
Thomas Monjalon Oct. 20, 2020, 11:50 a.m. UTC | #2
05/09/2020 00:31, Stephen Hemminger:
> If using lots of queues and ports, and having per port or per queue
> metrics it is easy to exceed the upper bound of the metric library.
> Move the limit into rte_config where user can change it.
> 
> Ideally, there would be no upper bound and a dynamic structure
> such as red-black tree or hash table would be used for these.
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> --- a/config/rte_config.h
> +++ b/config/rte_config.h
> +/* rte_metrics defines */
> +#define RTE_METRICS_MAX_METRICS 256

Not sure we want to go in the direction of adding such tuning
in rte_config.h.
Stephen Hemminger Oct. 20, 2020, 3:02 p.m. UTC | #3
On Tue, 20 Oct 2020 13:50:55 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 05/09/2020 00:31, Stephen Hemminger:
> > If using lots of queues and ports, and having per port or per queue
> > metrics it is easy to exceed the upper bound of the metric library.
> > Move the limit into rte_config where user can change it.
> > 
> > Ideally, there would be no upper bound and a dynamic structure
> > such as red-black tree or hash table would be used for these.
> > 
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > --- a/config/rte_config.h
> > +++ b/config/rte_config.h
> > +/* rte_metrics defines */
> > +#define RTE_METRICS_MAX_METRICS 256  
> 
> Not sure we want to go in the direction of adding such tuning
> in rte_config.h.
> 
> 

The only other option is to rewrite rte_metrics to support a
dynamic data structure!
Thomas Monjalon Oct. 20, 2020, 3:15 p.m. UTC | #4
20/10/2020 17:02, Stephen Hemminger:
> Thomas Monjalon <thomas@monjalon.net> wrote:
> > 05/09/2020 00:31, Stephen Hemminger:
> > > If using lots of queues and ports, and having per port or per queue
> > > metrics it is easy to exceed the upper bound of the metric library.
> > > Move the limit into rte_config where user can change it.
> > > 
> > > Ideally, there would be no upper bound and a dynamic structure
> > > such as red-black tree or hash table would be used for these.
> > > 
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > > ---
> > > --- a/config/rte_config.h
> > > +++ b/config/rte_config.h
> > > +/* rte_metrics defines */
> > > +#define RTE_METRICS_MAX_METRICS 256  
> > 
> > Not sure we want to go in the direction of adding such tuning
> > in rte_config.h.
> 
> The only other option is to rewrite rte_metrics to support a
> dynamic data structure!

Yes it seems a better solution.

How rte_metrics will fit in the picture of the new telemetry?
Maybe we will deprecate rte_metrics in future?

Patch
diff mbox series

diff --git a/config/rte_config.h b/config/rte_config.h
index 9bb915347cb6..b880974f5787 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -104,6 +104,9 @@ 
 #define RTE_GRAPH_BURST_SIZE 256
 #define RTE_LIBRTE_GRAPH_STATS 1
 
+/* rte_metrics defines */
+#define RTE_METRICS_MAX_METRICS 256
+
 /****** driver defines ********/
 
 /* QuickAssist device */
diff --git a/lib/librte_metrics/rte_metrics.h b/lib/librte_metrics/rte_metrics.h
index fbe64ddf2b47..40f015b8bb93 100644
--- a/lib/librte_metrics/rte_metrics.h
+++ b/lib/librte_metrics/rte_metrics.h
@@ -34,7 +34,6 @@  extern int metrics_initialized;
 
 /** Maximum length of metric name (including null-terminator) */
 #define RTE_METRICS_MAX_NAME_LEN 64
-#define RTE_METRICS_MAX_METRICS 256
 
 /**
  * Global metric special id.