[PATCH 0/8] fix possible data truncation and conversion error

[PATCH 0/8] fix possible data truncation and conversion error

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.

The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.

And this patchset use the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data. Also, this
patchset optimize the display of some capability related variables
in ethdev by using hexadecimal data.

Huisong Li (8):
  telemetry: move to header to controllable range
  telemetry: add u32 telemetry data type API
  test: add test cases for u32 telemetry data API
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  ethdev: telemetry convert capability related variable to hex

 app/test/test_telemetry_data.c     | 86 +++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c     | 23 +++++++-
 lib/cryptodev/rte_cryptodev.c      |  2 +-
 lib/eal/common/eal_common_memory.c | 14 ++---
 lib/ethdev/rte_ethdev.c            | 26 +++++----
 lib/mempool/rte_mempool.c          | 24 ++++-----
 lib/telemetry/rte_telemetry.h      | 40 ++++++++++++--
 lib/telemetry/telemetry.c          | 25 ++++++++-
 lib/telemetry/telemetry_data.c     | 52 ++++++++++++++----
 lib/telemetry/telemetry_data.h     |  2 +
 lib/telemetry/telemetry_json.h     | 29 ++++++++++
 lib/telemetry/version.map          |  9 ++++
 12 files changed, 285 insertions(+), 47 deletions(-)

-- 
2.33.0

[PATCH 1/8] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside _RTE_TELEMETRY_H_ macro, which cause
this header is uncontrollable. So this patch moves this header to inside
_RTE_TELEMETRY_H_.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH 2/8] telemetry: add u32 telemetry data type API

[Huisong Li]

Currently, 32-bit integer value only is signed in telemetry. The u32 data
can not be assigned to signed 32-bit integer. However, assigning to u64 is
very wasteful, after all, the buffer capacity of each transfer is limited.
So it is necessary for 'u32' data to add usigned 32-bit integer and a
series of 'u32' APIs.

Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 35 +++++++++++++++++++++++
 lib/telemetry/telemetry.c      | 25 ++++++++++++++--
 lib/telemetry/telemetry_data.c | 52 ++++++++++++++++++++++++++++------
 lib/telemetry/telemetry_data.h |  2 ++
 lib/telemetry/telemetry_json.h | 29 +++++++++++++++++++
 lib/telemetry/version.map      |  9 ++++++
 6 files changed, 141 insertions(+), 11 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..1ffa1a6632 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -42,6 +43,7 @@ struct rte_tel_data;
 enum rte_tel_value_type {
 	RTE_TEL_STRING_VAL, /** a string value */
 	RTE_TEL_INT_VAL,    /** a signed 32-bit int value */
+	RTE_TEL_U32_VAL,    /** an unsigned 32-bit int value */
 	RTE_TEL_U64_VAL,    /** an unsigned 64-bit int value */
 	RTE_TEL_CONTAINER, /** a container struct */
 };
@@ -117,6 +119,21 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
 int
 rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
 
+/**
+ * Add a uint32_t to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_U32_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_u32(struct rte_tel_data *d, uint32_t x);
+
 /**
  * Add a uint64_t to an array.
  * The array must have been started by rte_tel_data_start_array() with
@@ -189,6 +206,24 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
 int
 rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
 
+/**
+ * Add a uint32_t value to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of name.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_u32(struct rte_tel_data *d,
+		const char *name, uint32_t val);
+
 /**
  * Add a uint64_t value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 8fbb4f3060..b52fcae713 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -167,8 +167,9 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 	size_t used = 0;
 	unsigned int i;
 
-	if (d->type != RTE_TEL_DICT && d->type != RTE_TEL_ARRAY_U64 &&
-		d->type != RTE_TEL_ARRAY_INT && d->type != RTE_TEL_ARRAY_STRING)
+	if (d->type != RTE_TEL_DICT && d->type != RTE_TEL_ARRAY_U32 &&
+	    d->type != RTE_TEL_ARRAY_U64 && d->type != RTE_TEL_ARRAY_INT &&
+	    d->type != RTE_TEL_ARRAY_STRING)
 		return snprintf(out_buf, buf_len, "null");
 
 	used = rte_tel_json_empty_array(out_buf, buf_len, 0);
@@ -177,6 +178,11 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 			used = rte_tel_json_add_array_u64(out_buf,
 				buf_len, used,
 				d->data.array[i].u64val);
+	if (d->type == RTE_TEL_ARRAY_U32)
+		for (i = 0; i < d->data_len; i++)
+			used = rte_tel_json_add_array_u32(out_buf,
+				buf_len, used,
+				d->data.array[i].u32val);
 	if (d->type == RTE_TEL_ARRAY_INT)
 		for (i = 0; i < d->data_len; i++)
 			used = rte_tel_json_add_array_int(out_buf,
@@ -201,6 +207,11 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 						buf_len, used,
 						v->name, v->value.ival);
 				break;
+			case RTE_TEL_U32_VAL:
+				used = rte_tel_json_add_obj_u32(out_buf,
+						buf_len, used,
+						v->name, v->value.u32val);
+				break;
 			case RTE_TEL_U64_VAL:
 				used = rte_tel_json_add_obj_u64(out_buf,
 						buf_len, used,
@@ -268,6 +279,11 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 						buf_len, used,
 						v->name, v->value.ival);
 				break;
+			case RTE_TEL_U32_VAL:
+				used = rte_tel_json_add_obj_u32(cb_data_buf,
+						buf_len, used,
+						v->name, v->value.u32val);
+				break;
 			case RTE_TEL_U64_VAL:
 				used = rte_tel_json_add_obj_u64(cb_data_buf,
 						buf_len, used,
@@ -293,6 +309,7 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 
 	case RTE_TEL_ARRAY_STRING:
 	case RTE_TEL_ARRAY_INT:
+	case RTE_TEL_ARRAY_U32:
 	case RTE_TEL_ARRAY_U64:
 	case RTE_TEL_ARRAY_CONTAINER:
 		used = rte_tel_json_empty_array(cb_data_buf, buf_len, 0);
@@ -306,6 +323,10 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 				used = rte_tel_json_add_array_int(cb_data_buf,
 						buf_len, used,
 						d->data.array[i].ival);
+			else if (d->type == RTE_TEL_ARRAY_U32)
+				used = rte_tel_json_add_array_u32(cb_data_buf,
+						buf_len, used,
+						d->data.array[i].u32val);
 			else if (d->type == RTE_TEL_ARRAY_U64)
 				used = rte_tel_json_add_array_u64(cb_data_buf,
 						buf_len, used,
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..366cb2669a 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -18,8 +18,9 @@ rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 	enum tel_container_types array_types[] = {
 			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
 			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
-			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 2 */
-			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
+			RTE_TEL_ARRAY_U32,    /* RTE_TEL_u32_VAL = 2 */
+			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 3 */
+			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 4 */
 	};
 	d->type = array_types[type];
 	d->data_len = 0;
@@ -69,6 +70,17 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
 	return 0;
 }
 
+int
+rte_tel_data_add_array_u32(struct rte_tel_data *d, uint32_t x)
+{
+	if (d->type != RTE_TEL_ARRAY_U32)
+		return -EINVAL;
+	if (d->data_len >= RTE_TEL_MAX_ARRAY_ENTRIES)
+		return -ENOSPC;
+	d->data.array[d->data_len++].u32val = x;
+	return 0;
+}
+
 int
 rte_tel_data_add_array_u64(struct rte_tel_data *d, uint64_t x)
 {
@@ -85,9 +97,10 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep)
 {
 	if (d->type != RTE_TEL_ARRAY_CONTAINER ||
-			(val->type != RTE_TEL_ARRAY_U64
-			&& val->type != RTE_TEL_ARRAY_INT
-			&& val->type != RTE_TEL_ARRAY_STRING))
+			(val->type != RTE_TEL_ARRAY_U32 &&
+			 val->type != RTE_TEL_ARRAY_U64 &&
+			 val->type != RTE_TEL_ARRAY_INT &&
+			 val->type != RTE_TEL_ARRAY_STRING))
 		return -EINVAL;
 	if (d->data_len >= RTE_TEL_MAX_ARRAY_ENTRIES)
 		return -ENOSPC;
@@ -159,6 +172,26 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_u32(struct rte_tel_data *d,
+		const char *name, uint32_t val)
+{
+	struct tel_dict_entry *e = &d->data.dict[d->data_len];
+	if (d->type != RTE_TEL_DICT)
+		return -EINVAL;
+	if (d->data_len >= RTE_TEL_MAX_DICT_ENTRIES)
+		return -ENOSPC;
+
+	if (!valid_name(name))
+		return -EINVAL;
+
+	d->data_len++;
+	e->type = RTE_TEL_U32_VAL;
+	e->value.u32val = val;
+	const size_t bytes = strlcpy(e->name, name, RTE_TEL_MAX_STRING_LEN);
+	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
+}
+
 int
 rte_tel_data_add_dict_u64(struct rte_tel_data *d,
 		const char *name, uint64_t val)
@@ -185,10 +218,11 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 {
 	struct tel_dict_entry *e = &d->data.dict[d->data_len];
 
-	if (d->type != RTE_TEL_DICT || (val->type != RTE_TEL_ARRAY_U64
-			&& val->type != RTE_TEL_ARRAY_INT
-			&& val->type != RTE_TEL_ARRAY_STRING
-			&& val->type != RTE_TEL_DICT))
+	if (d->type != RTE_TEL_DICT || (val->type != RTE_TEL_ARRAY_U32 &&
+					val->type != RTE_TEL_ARRAY_U64 &&
+					val->type != RTE_TEL_ARRAY_INT &&
+					val->type != RTE_TEL_ARRAY_STRING &&
+					val->type != RTE_TEL_DICT))
 		return -EINVAL;
 	if (d->data_len >= RTE_TEL_MAX_DICT_ENTRIES)
 		return -ENOSPC;
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 26aa28e72c..ca0a895edb 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -13,6 +13,7 @@ enum tel_container_types {
 	RTE_TEL_DICT,	      /** name-value pairs, of individual value type */
 	RTE_TEL_ARRAY_STRING, /** array of string values only */
 	RTE_TEL_ARRAY_INT,    /** array of signed, 32-bit int values */
+	RTE_TEL_ARRAY_U32,    /** array of unsigned 32-bit int values */
 	RTE_TEL_ARRAY_U64,    /** array of unsigned 64-bit int values */
 	RTE_TEL_ARRAY_CONTAINER, /** array of container structs */
 };
@@ -29,6 +30,7 @@ struct container {
 union tel_value {
 	char sval[RTE_TEL_MAX_STRING_LEN];
 	int ival;
+	uint32_t u32val;
 	uint64_t u64val;
 	struct container container;
 };
diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
index e3fae7c30d..05762ec89a 100644
--- a/lib/telemetry/telemetry_json.h
+++ b/lib/telemetry/telemetry_json.h
@@ -146,6 +146,19 @@ rte_tel_json_add_array_int(char *buf, const int len, const int used, int val)
 	return ret == 0 ? used : end + ret;
 }
 
+/* Appends a uint32_t into the JSON array in the provided buffer. */
+static inline int
+rte_tel_json_add_array_u32(char *buf, const int len, const int used,
+		uint32_t val)
+{
+	int ret, end = used - 1; /* strip off final delimiter */
+	if (used <= 2) /* assume empty, since minimum is '[]' */
+		return __json_snprintf(buf, len, "[%u]", val);
+
+	ret = __json_snprintf(buf + end, len - end, ",%u]", val);
+	return ret == 0 ? used : end + ret;
+}
+
 /* Appends a uint64_t into the JSON array in the provided buffer. */
 static inline int
 rte_tel_json_add_array_u64(char *buf, const int len, const int used,
@@ -175,6 +188,22 @@ rte_tel_json_add_array_json(char *buf, const int len, const int used,
 	return ret == 0 ? used : end + ret;
 }
 
+/**
+ * Add a new element with uint32_t value to the JSON object stored in the
+ * provided buffer.
+ */
+static inline int
+rte_tel_json_add_obj_u32(char *buf, const int len, const int used,
+		const char *name, uint32_t val)
+{
+	int ret, end = used - 1;
+	if (used <= 2) /* assume empty, since minimum is '{}' */
+		return __json_snprintf(buf, len, "{\"%s\":%u}", name, val);
+
+	ret = __json_snprintf(buf + end, len - end, ",\"%s\":%u}", name, val);
+	return ret == 0 ? used : end + ret;
+}
+
 /**
  * Add a new element with uint64_t value to the JSON object stored in the
  * provided buffer.
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..3d1fb15637 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_u32;
+	rte_tel_data_add_dict_u32;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH 3/8] test: add test cases for u32 telemetry data API

[Huisong Li]

Add test cases for u32 telemetry data API.

Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 app/test/test_telemetry_data.c | 86 +++++++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c | 23 ++++++++-
 2 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..6c500f2e34 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -278,6 +278,17 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_case_array_u32(void)
+{
+	uint32_t i;
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_U32_VAL);
+	for (i = 0; i < 5; i++)
+		rte_tel_data_add_array_u32(&response_data, i);
+	return CHECK_OUTPUT("[0,1,2,3,4]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +300,21 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_add_dict_u32(void)
+{
+	uint32_t i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 5; i++) {
+		sprintf(name_of_value, "dict_%u", i);
+		rte_tel_data_add_dict_u32(&response_data, name_of_value, i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -304,6 +330,32 @@ test_case_add_dict_u64(void)
 	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
 }
 
+static int
+test_dict_with_array_u32_values(void)
+{
+	uint32_t i;
+
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_U32_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_U32_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 10; i++) {
+		rte_tel_data_add_array_u32(child_data, i);
+		rte_tel_data_add_array_u32(child_data2, i);
+	}
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[0,1,2,3,4,5,6,7,8,9],\"dict_1\":[0,1,2,3,4,5,6,7,8,9]}");
+}
+
 static int
 test_dict_with_array_u64_values(void)
 {
@@ -330,6 +382,30 @@ test_dict_with_array_u64_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[0,1,2,3,4,5,6,7,8,9],\"dict_1\":[0,1,2,3,4,5,6,7,8,9]}");
 }
 
+static int
+test_array_with_array_u32_values(void)
+{
+	uint32_t i;
+
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_U32_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_U32_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	for (i = 0; i < 5; i++) {
+		rte_tel_data_add_array_u32(child_data, i);
+		rte_tel_data_add_array_u32(child_data2, i);
+	}
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[0,1,2,3,4],[0,1,2,3,4]]");
+}
+
+
 static int
 test_array_with_array_u64_values(void)
 {
@@ -428,14 +504,20 @@ telemetry_data_autotest(void)
 			test_null_return,
 			test_simple_string,
 			test_case_array_string,
-			test_case_array_int, test_case_array_u64,
-			test_case_add_dict_int, test_case_add_dict_u64,
+			test_case_array_int,
+			test_case_array_u32,
+			test_case_array_u64,
+			test_case_add_dict_int,
+			test_case_add_dict_u32,
+			test_case_add_dict_u64,
 			test_case_add_dict_string,
 			test_dict_with_array_int_values,
+			test_dict_with_array_u32_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
+			test_array_with_array_u32_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
 			test_string_char_escaping,
diff --git a/app/test/test_telemetry_json.c b/app/test/test_telemetry_json.c
index 184c3ba9f1..e25442f8f0 100644
--- a/app/test/test_telemetry_json.c
+++ b/app/test/test_telemetry_json.c
@@ -31,7 +31,25 @@ test_basic_array(void)
 }
 
 static int
-test_basic_obj(void)
+test_basic_obj_u32(void)
+{
+	const char *expected = "{\"weddings\":4,\"funerals\":1}";
+	char buf[1024];
+	int used = 0;
+
+	used = rte_tel_json_add_obj_u32(buf, sizeof(buf), used,
+		"weddings", 4);
+	used = rte_tel_json_add_obj_u32(buf, sizeof(buf), used,
+		"funerals", 1);
+
+	printf("%s: buf = '%s', expected = '%s'\n", __func__, buf, expected);
+	if (used != (int)strlen(expected))
+		return -1;
+	return strncmp(expected, buf, sizeof(buf));
+}
+
+static int
+test_basic_obj_u64(void)
 {
 	const char *expected = "{\"weddings\":4,\"funerals\":1}";
 	char buf[1024];
@@ -195,7 +213,8 @@ test_telemetry_json(void)
 	unsigned int i;
 	test_fn fns[] = {
 			test_basic_array,
-			test_basic_obj,
+			test_basic_obj_u32,
+			test_basic_obj_u64,
 			test_overflow_array,
 			test_overflow_obj,
 			test_large_array_element,
-- 
2.33.0

[PATCH 4/8] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..dfb269970e 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u32(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u32(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH 5/8] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..c665fa5e14 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u32(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u32(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u32(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u32(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u32(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u32(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u32(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u32(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u32(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH 6/8] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data need
to use the 'u32' telemetry API to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..8e19411164 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u32(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH 7/8] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..b7981507da 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u32(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1148,8 +1148,8 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 				  sock_stats.heap_allocsz_bytes);
 	rte_tel_data_add_dict_u64(d, "Greatest_free_size",
 				  sock_stats.greatest_free_size);
-	rte_tel_data_add_dict_u64(d, "Alloc_count", sock_stats.alloc_count);
-	rte_tel_data_add_dict_u64(d, "Free_count", sock_stats.free_count);
+	rte_tel_data_add_dict_u32(d, "Alloc_count", sock_stats.alloc_count);
+	rte_tel_data_add_dict_u32(d, "Free_count", sock_stats.free_count);
 
 	return 0;
 }
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u32(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u32(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH 8/8] ethdev: telemetry convert capability related variable to hex

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are suitable
for hexadecimal display.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index dfb269970e..a496846ba4 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -5999,6 +5999,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 		const char *params,
 		struct rte_tel_data *d)
 {
+#define RTE_ETH_DEV_MAX_HEX_BUFFER_LEN (sizeof(uint64_t) + 3)\
+
+	char hex_buf[RTE_ETH_DEV_MAX_HEX_BUFFER_LEN];
 	struct rte_tel_data *rxq_state, *txq_state;
 	char mac_addr[RTE_ETHER_ADDR_FMT_SIZE];
 	struct rte_eth_dev *eth_dev;
@@ -6068,13 +6071,18 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u32(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
-			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
-			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
-			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	snprintf(hex_buf, RTE_ETH_DEV_MAX_HEX_BUFFER_LEN, "0x%x",
+		 eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_string(d, "dev_flags", hex_buf);
+	snprintf(hex_buf, RTE_ETH_DEV_MAX_HEX_BUFFER_LEN, "0x%"PRIx64"",
+		 eth_dev->data->dev_conf.rxmode.offloads);
+	rte_tel_data_add_dict_string(d, "rx_offloads", hex_buf);
+	snprintf(hex_buf, RTE_ETH_DEV_MAX_HEX_BUFFER_LEN, "0x%"PRIx64"",
+		 eth_dev->data->dev_conf.txmode.offloads);
+	rte_tel_data_add_dict_string(d, "tx_offloads", hex_buf);
+	snprintf(hex_buf, RTE_ETH_DEV_MAX_HEX_BUFFER_LEN, "0x%"PRIx64"",
+		 eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	rte_tel_data_add_dict_string(d, "ethdev_rss_hf", hex_buf);
 
 	return 0;
 }
-- 
2.33.0

RE: [PATCH 8/8] ethdev: telemetry convert capability related variable to hex

[Morten Brørup]

+To: Bruce and Stephen might also have opinions on this.

> From: Huisong Li [mailto:lihuisong@huawei.com]
> Sent: Thursday, 8 December 2022 09.06
> 
> The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are suitable
> for hexadecimal display.
> 
> Like:
>  -->old display by input /ethdev/info,0
>       "dev_flags": 3,
>       "rx_offloads": 524288,
>       "tx_offloads": 65536,
>       "ethdev_rss_hf": 9100
> 
>  --> now display
>      "dev_flags": "0x3",
>      "rx_offloads": "0x80000",
>      "tx_offloads": "0x10000",
>      "ethdev_rss_hf": "0x238c"

This is certainly good for human consumption, but perhaps not for machine consumption (where a number type is more appropriate than a string type).

Unfortunately, the JSON format [RFC7159] does not allow hexadecimal numbers, so hexadecimal values (if supported) have to be passed as strings.

[RFC7159]: https://www.rfc-editor.org/rfc/rfc7159

This leaves us with the key question:

Do we want to provide integer values like these as hexadecimal encoded strings?

If we do, then the telemetry library should provide the functions to do it, rather than doing it here (and everywhere else, where relevant).

Re: [PATCH 8/8] ethdev: telemetry convert capability related variable to hex

[Bruce Richardson]

On Thu, Dec 08, 2022 at 11:55:16AM +0100, Morten Brørup wrote:
> +To: Bruce and Stephen might also have opinions on this.
> 
> > From: Huisong Li [mailto:lihuisong@huawei.com]
> > Sent: Thursday, 8 December 2022 09.06
> > 
> > The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are suitable
> > for hexadecimal display.
> > 
> > Like:
> >  -->old display by input /ethdev/info,0
> >       "dev_flags": 3,
> >       "rx_offloads": 524288,
> >       "tx_offloads": 65536,
> >       "ethdev_rss_hf": 9100
> > 
> >  --> now display
> >      "dev_flags": "0x3",
> >      "rx_offloads": "0x80000",
> >      "tx_offloads": "0x10000",
> >      "ethdev_rss_hf": "0x238c"
> 
> This is certainly good for human consumption, but perhaps not for machine consumption (where a number type is more appropriate than a string type).
> 
> Unfortunately, the JSON format [RFC7159] does not allow hexadecimal numbers, so hexadecimal values (if supported) have to be passed as strings.
> 
> [RFC7159]: https://www.rfc-editor.org/rfc/rfc7159
> 
> This leaves us with the key question:
> 
> Do we want to provide integer values like these as hexadecimal encoded strings?
> 
> If we do, then the telemetry library should provide the functions to do it, rather than doing it here (and everywhere else, where relevant).
> 

My initial thought was "no, we shouldn't do that, and just treat numbers as
numbers", and let the end-user display software worry about formatting it
correctly. However, I have since changed my mind, in that:

* Although these are numbers, they are not used for computation, or
  comparison
* Having them as strings makes them more useful for "dumb-client"
  connections, like that of the telemetry script in DPDK
* If display software is aware of the significance of these values and does
  want to do additional parsing of the flags, e.g. to map them to named
  flags, converting a string back to a number is not a difficult task.
* These values are not changing between polls, so any convertion/processing
  of the flags to be done before display only needs to be done once (except
  in very rare circumstances of a port reconfiguration)

So overall, I would tend to agree with your proposal, in that it would be
good for telemetry lib to provide this functionality.

Regards,
/Bruce

Re: [PATCH 8/8] ethdev: telemetry convert capability related variable to hex

[lihuisong (C)]

在 2022/12/8 19:20, Bruce Richardson 写道:
> On Thu, Dec 08, 2022 at 11:55:16AM +0100, Morten Brørup wrote:
>> +To: Bruce and Stephen might also have opinions on this.
>>
>>> From: Huisong Li [mailto:lihuisong@huawei.com]
>>> Sent: Thursday, 8 December 2022 09.06
>>>
>>> The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are suitable
>>> for hexadecimal display.
>>>
>>> Like:
>>>   -->old display by input /ethdev/info,0
>>>        "dev_flags": 3,
>>>        "rx_offloads": 524288,
>>>        "tx_offloads": 65536,
>>>        "ethdev_rss_hf": 9100
>>>
>>>   --> now display
>>>       "dev_flags": "0x3",
>>>       "rx_offloads": "0x80000",
>>>       "tx_offloads": "0x10000",
>>>       "ethdev_rss_hf": "0x238c"
>> This is certainly good for human consumption, but perhaps not for machine consumption (where a number type is more appropriate than a string type).
>>
>> Unfortunately, the JSON format [RFC7159] does not allow hexadecimal numbers, so hexadecimal values (if supported) have to be passed as strings.
>>
>> [RFC7159]: https://www.rfc-editor.org/rfc/rfc7159
>>
>> This leaves us with the key question:
>>
>> Do we want to provide integer values like these as hexadecimal encoded strings?
>>
>> If we do, then the telemetry library should provide the functions to do it, rather than doing it here (and everywhere else, where relevant).
>>
> My initial thought was "no, we shouldn't do that, and just treat numbers as
> numbers", and let the end-user display software worry about formatting it
> correctly. However, I have since changed my mind, in that:
>
> * Although these are numbers, they are not used for computation, or
>    comparison
> * Having them as strings makes them more useful for "dumb-client"
>    connections, like that of the telemetry script in DPDK
> * If display software is aware of the significance of these values and does
>    want to do additional parsing of the flags, e.g. to map them to named
>    flags, converting a string back to a number is not a difficult task.
> * These values are not changing between polls, so any convertion/processing
>    of the flags to be done before display only needs to be done once (except
>    in very rare circumstances of a port reconfiguration)
>
> So overall, I would tend to agree with your proposal, in that it would be
> good for telemetry lib to provide this functionality.
All right. Thanks for your suggestion. I will do it in V2.
>
> Regards,
> /Bruce
> .

[PATCH V2 00/11] telemetry: add u32 value type and hex integer string API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.

The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.

This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.

In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library. 

---
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (11):
  telemetry: move to header to controllable range
  telemetry: add u32 value type
  test: add test cases for adding u32 value API
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: refactor mapping betwween value and array type
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer values API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 249 ++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c     |  23 ++-
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  14 +-
 lib/ethdev/rte_ethdev.c            |  13 +-
 lib/mempool/rte_mempool.c          |  24 +--
 lib/telemetry/rte_telemetry.h      | 112 ++++++++++++-
 lib/telemetry/telemetry.c          |  25 ++-
 lib/telemetry/telemetry_data.c     | 122 ++++++++++++--
 lib/telemetry/telemetry_data.h     |   2 +
 lib/telemetry/telemetry_json.h     |  29 ++++
 lib/telemetry/version.map          |  14 ++
 12 files changed, 581 insertions(+), 48 deletions(-)

-- 
2.33.0

[PATCH V2 01/11] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is uncontrollable. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V2 02/11] telemetry: add u32 value type

[Huisong Li]

Currently, 32-bit integer value only is signed in telemetry. The u32 data
can not be assigned to signed 32-bit integer. However, assigning to u64 is
very wasteful, after all, the buffer capacity of each transfer is limited.
So it is necessary for 'u32' data to add usigned 32-bit integer type and
container type.

Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 35 ++++++++++++++++++++++++
 lib/telemetry/telemetry.c      | 25 +++++++++++++++--
 lib/telemetry/telemetry_data.c | 50 ++++++++++++++++++++++++++++------
 lib/telemetry/telemetry_data.h |  2 ++
 lib/telemetry/telemetry_json.h | 29 ++++++++++++++++++++
 lib/telemetry/version.map      |  9 ++++++
 6 files changed, 140 insertions(+), 10 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..5efdafc156 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -44,6 +45,7 @@ enum rte_tel_value_type {
 	RTE_TEL_INT_VAL,    /** a signed 32-bit int value */
 	RTE_TEL_U64_VAL,    /** an unsigned 64-bit int value */
 	RTE_TEL_CONTAINER, /** a container struct */
+	RTE_TEL_U32_VAL,    /** an unsigned 32-bit int value */
 };
 
 /**
@@ -117,6 +119,21 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
 int
 rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
 
+/**
+ * Add a uint32_t to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_U32_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_u32(struct rte_tel_data *d, uint32_t x);
+
 /**
  * Add a uint64_t to an array.
  * The array must have been started by rte_tel_data_start_array() with
@@ -189,6 +206,24 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
 int
 rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
 
+/**
+ * Add a uint32_t value to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of name.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_u32(struct rte_tel_data *d,
+		const char *name, uint32_t val);
+
 /**
  * Add a uint64_t value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 8fbb4f3060..b52fcae713 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -167,8 +167,9 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 	size_t used = 0;
 	unsigned int i;
 
-	if (d->type != RTE_TEL_DICT && d->type != RTE_TEL_ARRAY_U64 &&
-		d->type != RTE_TEL_ARRAY_INT && d->type != RTE_TEL_ARRAY_STRING)
+	if (d->type != RTE_TEL_DICT && d->type != RTE_TEL_ARRAY_U32 &&
+	    d->type != RTE_TEL_ARRAY_U64 && d->type != RTE_TEL_ARRAY_INT &&
+	    d->type != RTE_TEL_ARRAY_STRING)
 		return snprintf(out_buf, buf_len, "null");
 
 	used = rte_tel_json_empty_array(out_buf, buf_len, 0);
@@ -177,6 +178,11 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 			used = rte_tel_json_add_array_u64(out_buf,
 				buf_len, used,
 				d->data.array[i].u64val);
+	if (d->type == RTE_TEL_ARRAY_U32)
+		for (i = 0; i < d->data_len; i++)
+			used = rte_tel_json_add_array_u32(out_buf,
+				buf_len, used,
+				d->data.array[i].u32val);
 	if (d->type == RTE_TEL_ARRAY_INT)
 		for (i = 0; i < d->data_len; i++)
 			used = rte_tel_json_add_array_int(out_buf,
@@ -201,6 +207,11 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 						buf_len, used,
 						v->name, v->value.ival);
 				break;
+			case RTE_TEL_U32_VAL:
+				used = rte_tel_json_add_obj_u32(out_buf,
+						buf_len, used,
+						v->name, v->value.u32val);
+				break;
 			case RTE_TEL_U64_VAL:
 				used = rte_tel_json_add_obj_u64(out_buf,
 						buf_len, used,
@@ -268,6 +279,11 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 						buf_len, used,
 						v->name, v->value.ival);
 				break;
+			case RTE_TEL_U32_VAL:
+				used = rte_tel_json_add_obj_u32(cb_data_buf,
+						buf_len, used,
+						v->name, v->value.u32val);
+				break;
 			case RTE_TEL_U64_VAL:
 				used = rte_tel_json_add_obj_u64(cb_data_buf,
 						buf_len, used,
@@ -293,6 +309,7 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 
 	case RTE_TEL_ARRAY_STRING:
 	case RTE_TEL_ARRAY_INT:
+	case RTE_TEL_ARRAY_U32:
 	case RTE_TEL_ARRAY_U64:
 	case RTE_TEL_ARRAY_CONTAINER:
 		used = rte_tel_json_empty_array(cb_data_buf, buf_len, 0);
@@ -306,6 +323,10 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 				used = rte_tel_json_add_array_int(cb_data_buf,
 						buf_len, used,
 						d->data.array[i].ival);
+			else if (d->type == RTE_TEL_ARRAY_U32)
+				used = rte_tel_json_add_array_u32(cb_data_buf,
+						buf_len, used,
+						d->data.array[i].u32val);
 			else if (d->type == RTE_TEL_ARRAY_U64)
 				used = rte_tel_json_add_array_u64(cb_data_buf,
 						buf_len, used,
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..c120bf6281 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -18,8 +18,9 @@ rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 	enum tel_container_types array_types[] = {
 			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
 			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
-			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 2 */
+			RTE_TEL_ARRAY_U64,    /* RTE_TEL_U64_VAL = 2 */
 			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
+			RTE_TEL_ARRAY_U32, /* RTE_TEL_U32_VAL = 4 */
 	};
 	d->type = array_types[type];
 	d->data_len = 0;
@@ -69,6 +70,17 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
 	return 0;
 }
 
+int
+rte_tel_data_add_array_u32(struct rte_tel_data *d, uint32_t x)
+{
+	if (d->type != RTE_TEL_ARRAY_U32)
+		return -EINVAL;
+	if (d->data_len >= RTE_TEL_MAX_ARRAY_ENTRIES)
+		return -ENOSPC;
+	d->data.array[d->data_len++].u32val = x;
+	return 0;
+}
+
 int
 rte_tel_data_add_array_u64(struct rte_tel_data *d, uint64_t x)
 {
@@ -85,9 +97,10 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep)
 {
 	if (d->type != RTE_TEL_ARRAY_CONTAINER ||
-			(val->type != RTE_TEL_ARRAY_U64
-			&& val->type != RTE_TEL_ARRAY_INT
-			&& val->type != RTE_TEL_ARRAY_STRING))
+			(val->type != RTE_TEL_ARRAY_U32 &&
+			 val->type != RTE_TEL_ARRAY_U64 &&
+			 val->type != RTE_TEL_ARRAY_INT &&
+			 val->type != RTE_TEL_ARRAY_STRING))
 		return -EINVAL;
 	if (d->data_len >= RTE_TEL_MAX_ARRAY_ENTRIES)
 		return -ENOSPC;
@@ -159,6 +172,26 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_u32(struct rte_tel_data *d,
+		const char *name, uint32_t val)
+{
+	struct tel_dict_entry *e = &d->data.dict[d->data_len];
+	if (d->type != RTE_TEL_DICT)
+		return -EINVAL;
+	if (d->data_len >= RTE_TEL_MAX_DICT_ENTRIES)
+		return -ENOSPC;
+
+	if (!valid_name(name))
+		return -EINVAL;
+
+	d->data_len++;
+	e->type = RTE_TEL_U32_VAL;
+	e->value.u32val = val;
+	const size_t bytes = strlcpy(e->name, name, RTE_TEL_MAX_STRING_LEN);
+	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
+}
+
 int
 rte_tel_data_add_dict_u64(struct rte_tel_data *d,
 		const char *name, uint64_t val)
@@ -185,10 +218,11 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 {
 	struct tel_dict_entry *e = &d->data.dict[d->data_len];
 
-	if (d->type != RTE_TEL_DICT || (val->type != RTE_TEL_ARRAY_U64
-			&& val->type != RTE_TEL_ARRAY_INT
-			&& val->type != RTE_TEL_ARRAY_STRING
-			&& val->type != RTE_TEL_DICT))
+	if (d->type != RTE_TEL_DICT || (val->type != RTE_TEL_ARRAY_U32 &&
+					val->type != RTE_TEL_ARRAY_U64 &&
+					val->type != RTE_TEL_ARRAY_INT &&
+					val->type != RTE_TEL_ARRAY_STRING &&
+					val->type != RTE_TEL_DICT))
 		return -EINVAL;
 	if (d->data_len >= RTE_TEL_MAX_DICT_ENTRIES)
 		return -ENOSPC;
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 26aa28e72c..1455bf77d7 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -15,6 +15,7 @@ enum tel_container_types {
 	RTE_TEL_ARRAY_INT,    /** array of signed, 32-bit int values */
 	RTE_TEL_ARRAY_U64,    /** array of unsigned 64-bit int values */
 	RTE_TEL_ARRAY_CONTAINER, /** array of container structs */
+	RTE_TEL_ARRAY_U32,    /** array of unsigned 32-bit int values */
 };
 
 struct container {
@@ -29,6 +30,7 @@ struct container {
 union tel_value {
 	char sval[RTE_TEL_MAX_STRING_LEN];
 	int ival;
+	uint32_t u32val;
 	uint64_t u64val;
 	struct container container;
 };
diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
index e3fae7c30d..05762ec89a 100644
--- a/lib/telemetry/telemetry_json.h
+++ b/lib/telemetry/telemetry_json.h
@@ -146,6 +146,19 @@ rte_tel_json_add_array_int(char *buf, const int len, const int used, int val)
 	return ret == 0 ? used : end + ret;
 }
 
+/* Appends a uint32_t into the JSON array in the provided buffer. */
+static inline int
+rte_tel_json_add_array_u32(char *buf, const int len, const int used,
+		uint32_t val)
+{
+	int ret, end = used - 1; /* strip off final delimiter */
+	if (used <= 2) /* assume empty, since minimum is '[]' */
+		return __json_snprintf(buf, len, "[%u]", val);
+
+	ret = __json_snprintf(buf + end, len - end, ",%u]", val);
+	return ret == 0 ? used : end + ret;
+}
+
 /* Appends a uint64_t into the JSON array in the provided buffer. */
 static inline int
 rte_tel_json_add_array_u64(char *buf, const int len, const int used,
@@ -175,6 +188,22 @@ rte_tel_json_add_array_json(char *buf, const int len, const int used,
 	return ret == 0 ? used : end + ret;
 }
 
+/**
+ * Add a new element with uint32_t value to the JSON object stored in the
+ * provided buffer.
+ */
+static inline int
+rte_tel_json_add_obj_u32(char *buf, const int len, const int used,
+		const char *name, uint32_t val)
+{
+	int ret, end = used - 1;
+	if (used <= 2) /* assume empty, since minimum is '{}' */
+		return __json_snprintf(buf, len, "{\"%s\":%u}", name, val);
+
+	ret = __json_snprintf(buf + end, len - end, ",\"%s\":%u}", name, val);
+	return ret == 0 ? used : end + ret;
+}
+
 /**
  * Add a new element with uint64_t value to the JSON object stored in the
  * provided buffer.
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..3d1fb15637 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_u32;
+	rte_tel_data_add_dict_u32;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V2 03/11] test: add test cases for adding u32 value API

[Huisong Li]

Add test cases for adding u32 value API.

Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 app/test/test_telemetry_data.c | 85 +++++++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c | 23 ++++++++-
 2 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..8ab3441cbe 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -278,6 +278,17 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_case_array_u32(void)
+{
+	uint32_t i;
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_U32_VAL);
+	for (i = 0; i < 5; i++)
+		rte_tel_data_add_array_u32(&response_data, i);
+	return CHECK_OUTPUT("[0,1,2,3,4]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +300,21 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_add_dict_u32(void)
+{
+	uint32_t i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 5; i++) {
+		sprintf(name_of_value, "dict_%u", i);
+		rte_tel_data_add_dict_u32(&response_data, name_of_value, i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -304,6 +330,32 @@ test_case_add_dict_u64(void)
 	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
 }
 
+static int
+test_dict_with_array_u32_values(void)
+{
+	uint32_t i;
+
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_U32_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_U32_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 10; i++) {
+		rte_tel_data_add_array_u32(child_data, i);
+		rte_tel_data_add_array_u32(child_data2, i);
+	}
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[0,1,2,3,4,5,6,7,8,9],\"dict_1\":[0,1,2,3,4,5,6,7,8,9]}");
+}
+
 static int
 test_dict_with_array_u64_values(void)
 {
@@ -330,6 +382,29 @@ test_dict_with_array_u64_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[0,1,2,3,4,5,6,7,8,9],\"dict_1\":[0,1,2,3,4,5,6,7,8,9]}");
 }
 
+static int
+test_array_with_array_u32_values(void)
+{
+	uint32_t i;
+
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_U32_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_U32_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	for (i = 0; i < 5; i++) {
+		rte_tel_data_add_array_u32(child_data, i);
+		rte_tel_data_add_array_u32(child_data2, i);
+	}
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[0,1,2,3,4],[0,1,2,3,4]]");
+}
+
 static int
 test_array_with_array_u64_values(void)
 {
@@ -428,14 +503,20 @@ telemetry_data_autotest(void)
 			test_null_return,
 			test_simple_string,
 			test_case_array_string,
-			test_case_array_int, test_case_array_u64,
-			test_case_add_dict_int, test_case_add_dict_u64,
+			test_case_array_int,
+			test_case_array_u32,
+			test_case_array_u64,
+			test_case_add_dict_int,
+			test_case_add_dict_u32,
+			test_case_add_dict_u64,
 			test_case_add_dict_string,
 			test_dict_with_array_int_values,
+			test_dict_with_array_u32_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
+			test_array_with_array_u32_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
 			test_string_char_escaping,
diff --git a/app/test/test_telemetry_json.c b/app/test/test_telemetry_json.c
index 184c3ba9f1..e25442f8f0 100644
--- a/app/test/test_telemetry_json.c
+++ b/app/test/test_telemetry_json.c
@@ -31,7 +31,25 @@ test_basic_array(void)
 }
 
 static int
-test_basic_obj(void)
+test_basic_obj_u32(void)
+{
+	const char *expected = "{\"weddings\":4,\"funerals\":1}";
+	char buf[1024];
+	int used = 0;
+
+	used = rte_tel_json_add_obj_u32(buf, sizeof(buf), used,
+		"weddings", 4);
+	used = rte_tel_json_add_obj_u32(buf, sizeof(buf), used,
+		"funerals", 1);
+
+	printf("%s: buf = '%s', expected = '%s'\n", __func__, buf, expected);
+	if (used != (int)strlen(expected))
+		return -1;
+	return strncmp(expected, buf, sizeof(buf));
+}
+
+static int
+test_basic_obj_u64(void)
 {
 	const char *expected = "{\"weddings\":4,\"funerals\":1}";
 	char buf[1024];
@@ -195,7 +213,8 @@ test_telemetry_json(void)
 	unsigned int i;
 	test_fn fns[] = {
 			test_basic_array,
-			test_basic_obj,
+			test_basic_obj_u32,
+			test_basic_obj_u64,
 			test_overflow_array,
 			test_overflow_obj,
 			test_large_array_element,
-- 
2.33.0

[PATCH V2 04/11] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..dfb269970e 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u32(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u32(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V2 05/11] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..c665fa5e14 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u32(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u32(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u32(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u32(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u32(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u32(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u32(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u32(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u32(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V2 06/11] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data need
to use the 'u32' telemetry API to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..8e19411164 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u32(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V2 07/11] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..b7981507da 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u32(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1148,8 +1148,8 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 				  sock_stats.heap_allocsz_bytes);
 	rte_tel_data_add_dict_u64(d, "Greatest_free_size",
 				  sock_stats.greatest_free_size);
-	rte_tel_data_add_dict_u64(d, "Alloc_count", sock_stats.alloc_count);
-	rte_tel_data_add_dict_u64(d, "Free_count", sock_stats.free_count);
+	rte_tel_data_add_dict_u32(d, "Alloc_count", sock_stats.alloc_count);
+	rte_tel_data_add_dict_u32(d, "Free_count", sock_stats.free_count);
 
 	return 0;
 }
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u32(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u32(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V2 08/11] telemetry: refactor mapping betwween value and array type

[Huisong Li]

Currently, use rte_tel_value_type as index of array to find the
tel_container_types in rte_tel_data_start_array. It's not good
for maintenance.

Fixes: ed1bfad7d384 ("telemetry: add functions for returning callback data")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/telemetry/telemetry_data.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index c120bf6281..f8efc37763 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -15,14 +15,30 @@
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
-	enum tel_container_types array_types[] = {
-			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
-			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
-			RTE_TEL_ARRAY_U64,    /* RTE_TEL_U64_VAL = 2 */
-			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
-			RTE_TEL_ARRAY_U32, /* RTE_TEL_U32_VAL = 4 */
+	struct {
+		enum rte_tel_value_type value_type;
+		enum tel_container_types array_type;
+	} value2array_types_map[] = {
+		{RTE_TEL_STRING_VAL, RTE_TEL_ARRAY_STRING},
+		{RTE_TEL_INT_VAL,    RTE_TEL_ARRAY_INT},
+		{RTE_TEL_U64_VAL,    RTE_TEL_ARRAY_U64},
+		{RTE_TEL_CONTAINER,  RTE_TEL_ARRAY_CONTAINER},
+		{RTE_TEL_U32_VAL,  RTE_TEL_ARRAY_U32},
 	};
-	d->type = array_types[type];
+	int array_types = -1;
+	uint16_t i;
+
+	for (i = 0; i < RTE_DIM(value2array_types_map); i++) {
+		if (type == value2array_types_map[i].value_type) {
+			array_types = value2array_types_map[i].array_type;
+			break;
+		}
+	}
+
+	if (array_types  == -1)
+		return -EINVAL;
+
+	d->type = array_types;
 	d->data_len = 0;
 	return 0;
 }
-- 
2.33.0

[PATCH V2 09/11] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a integer value as hexadecimal encoded style is
more expected for human consumption, such as, offload capability and
device falg. This patch introduces some APIs to add 'u32' and 'u64'
value as hexadecimal encoded string to array or dictionary.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 72 ++++++++++++++++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 46 ++++++++++++++++++++++
 lib/telemetry/version.map      |  5 +++
 3 files changed, 123 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 5efdafc156..dac87050da 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -170,6 +170,38 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a uint32_t to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_hex_u32_str(struct rte_tel_data *d, uint32_t x);
+
+/**
+ * Convert a uint64_t to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_hex_u64_str(struct rte_tel_data *d, uint64_t x);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -266,6 +298,46 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a uint32_t to hexadecimal encoded strings and add this string
+ * to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of
+ *   either name or value.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_hex_u32_str(struct rte_tel_data *d,
+				      const char *name, uint32_t val);
+
+/**
+ * Convert a uint64_t to hexadecimal encoded strings and add this string
+ * to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of
+ *   either name or value.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_hex_u64_str(struct rte_tel_data *d,
+				      const char *name, uint64_t val);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index f8efc37763..b195b79fa4 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,9 @@
 
 #include "telemetry_data.h"
 
+/* The string length is equal to (sizeof(uint64_t) * 2 + 3) */
+#define RTE_TEL_HEX_UINT_MAX_STRING_LEN 19
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -126,6 +130,26 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+int
+rte_tel_data_add_array_hex_u32_str(struct rte_tel_data *d, uint32_t x)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%x", x);
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
+int
+rte_tel_data_add_array_hex_u64_str(struct rte_tel_data *d, uint64_t x)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%"PRIx64"", x);
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -254,6 +278,28 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_hex_u32_str(struct rte_tel_data *d, const char *name,
+				  uint32_t val)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%x", val);
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
+int
+rte_tel_data_add_dict_hex_u64_str(struct rte_tel_data *d, const char *name,
+				  uint64_t val)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%"PRIx64"", val);
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 3d1fb15637..994414c47f 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -3,6 +3,11 @@ EXPERIMENTAL {
 
 	rte_tel_data_add_array_u32;
 	rte_tel_data_add_dict_u32;
+	rte_tel_data_add_array_hex_u32_str;
+	rte_tel_data_add_array_hex_u64_str;
+	rte_tel_data_add_dict_hex_u32_str;
+	rte_tel_data_add_dict_hex_u64_str;
+
 
 	local: *;
 };
-- 
2.33.0

[PATCH V2 10/11] test: add test cases for adding hex integer values API

[Huisong Li]

Add test cases for adding hexadecimal u32 and u64 values API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 app/test/test_telemetry_data.c | 164 +++++++++++++++++++++++++++++++++
 1 file changed, 164 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index 8ab3441cbe..7ce905c503 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -278,6 +278,89 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_case_array_with_array_hex_u32_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff1);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffff0\",\"0xfffffff1\"],[\"0x8ffff2\"]]");
+}
+
+static int
+test_case_array_with_array_hex_u64_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff0);
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffffffffffff0\",\"0xfffffffffffffff2\"]]");
+}
+
+static int
+test_case_dict_with_array_hex_u32_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff1);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffffff1);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0xfffffff0\",\"0xfffffff1\"],\"dict_1\":[\"0x8ffffff0\",\"0x8ffffff1\"]}");
+}
+
+static int
+test_case_dict_with_array_hex_u64_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff0);
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff1);
+	rte_tel_data_add_array_hex_u64_str(child_data2, 0x8ffffffffffffff0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0xfffffffffffffff0\",\"0xfffffffffffffff1\"],\"dict_1\":[\"0x8ffffffffffffff0\"]}");
+}
+
 static int
 test_case_array_u32(void)
 {
@@ -300,6 +383,47 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_hex_u32_str(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff1);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffff0\",\"0xfffffff1\"],[\"0x8ffff2\"]]");
+}
+
+static int
+test_case_array_hex_u64_str(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff0);
+	rte_tel_data_add_array_hex_u64_str(child_data2, 0x8ffffffffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffffffffffff0\"],[\"0x8ffffffffff2\"]]");
+}
+
 static int
 test_case_add_dict_u32(void)
 {
@@ -330,6 +454,38 @@ test_case_add_dict_u64(void)
 	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
 }
 
+static int
+test_case_add_dict_hex_u32_values(void)
+{
+	int i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 3; i++) {
+		sprintf(name_of_value, "dict_%d", i);
+		rte_tel_data_add_dict_hex_u32_str(&response_data, name_of_value,
+						  0xfffffff0 + i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":\"0xfffffff0\",\"dict_1\":\"0xfffffff1\",\"dict_2\":\"0xfffffff2\"}");
+}
+
+static int
+test_case_add_dict_hex_u64_values(void)
+{
+	int i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 2; i++) {
+		sprintf(name_of_value, "dict_%d", i);
+		rte_tel_data_add_dict_hex_u64_str(&response_data, name_of_value,
+						  0xfffffffff0 + i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":\"0xfffffffff0\",\"dict_1\":\"0xfffffffff1\"}");
+}
+
 static int
 test_dict_with_array_u32_values(void)
 {
@@ -509,16 +665,24 @@ telemetry_data_autotest(void)
 			test_case_add_dict_int,
 			test_case_add_dict_u32,
 			test_case_add_dict_u64,
+			test_case_array_hex_u32_str,
+			test_case_array_hex_u64_str,
 			test_case_add_dict_string,
+			test_case_add_dict_hex_u32_values,
+			test_case_add_dict_hex_u64_values,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u32_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_case_dict_with_array_hex_u32_values,
+			test_case_dict_with_array_hex_u64_values,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u32_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_case_array_with_array_hex_u32_values,
+			test_case_array_with_array_hex_u64_values,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V2 11/11] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index dfb269970e..f0fa00c773 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,12 +6068,13 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u32(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
+	rte_tel_data_add_dict_hex_u32_str(d, "dev_flags",
+			eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_hex_u64_str(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
+	rte_tel_data_add_dict_hex_u64_str(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_hex_u64_str(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

RE: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API

[Morten Brørup]

> From: Huisong Li [mailto:lihuisong@huawei.com]
> Sent: Friday, 9 December 2022 12.05
> 
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
> 
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
> 
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
> 
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
> 
> ---
>  -v2:
>     - fix ABI break warning.
>     - introduce two APIs to store u32 and u64 values as hexadecimal
>       encoded strings.

Looks good.

Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.

In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?


Series-acked-by: Morten Brørup <mb@smartsharesystems.com>

Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API

[fengchengwen]

LGTM
Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>

On 2022/12/9 19:04, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> ---
>   -v2:
>      - fix ABI break warning.
>      - introduce two APIs to store u32 and u64 values as hexadecimal
>        encoded strings.
>
> Huisong Li (11):
>    telemetry: move to header to controllable range
>    telemetry: add u32 value type
>    test: add test cases for adding u32 value API
>    ethdev: fix possible data truncation and conversion error
>    mempool: fix possible data truncation and conversion error
>    cryptodev: fix possible data conversion error
>    mem: possible data truncation and conversion error
>    telemetry: refactor mapping betwween value and array type
>    telemetry: support adding integer value as hexadecimal
>    test: add test cases for adding hex integer values API
>    ethdev: display capability values in hexadecimal format
>
>   app/test/test_telemetry_data.c     | 249 ++++++++++++++++++++++++++++-
>   app/test/test_telemetry_json.c     |  23 ++-
>   lib/cryptodev/rte_cryptodev.c      |   2 +-
>   lib/eal/common/eal_common_memory.c |  14 +-
>   lib/ethdev/rte_ethdev.c            |  13 +-
>   lib/mempool/rte_mempool.c          |  24 +--
>   lib/telemetry/rte_telemetry.h      | 112 ++++++++++++-
>   lib/telemetry/telemetry.c          |  25 ++-
>   lib/telemetry/telemetry_data.c     | 122 ++++++++++++--
>   lib/telemetry/telemetry_data.h     |   2 +
>   lib/telemetry/telemetry_json.h     |  29 ++++
>   lib/telemetry/version.map          |  14 ++
>   12 files changed, 581 insertions(+), 48 deletions(-)
>

Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API

[lihuisong (C)]

在 2022/12/10 2:24, Morten Brørup 写道:
>> From: Huisong Li [mailto:lihuisong@huawei.com]
>> Sent: Friday, 9 December 2022 12.05
>>
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation.
>>
>> The 'u32' data can not be assigned to signed 32-bit integer. However,
>> assigning to u64 is very wasteful, after all, the buffer capacity of
>> each transfer is limited. So it is necessary for 'u32' data to add
>> usigned 32-bit integer type and a series of 'u32' operation APIs.
>>
>> This patchset uses the new 'u32' API to resolve the problem of data
>> conversion error, and use the 'u64' API to add 'u64' data.
>>
>> In addition, this patchset introduces two APIs to store u32 and u64
>> values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>>   -v2:
>>      - fix ABI break warning.
>>      - introduce two APIs to store u32 and u64 values as hexadecimal
>>        encoded strings.
> Looks good.
>
> Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.
I think this name can represent the type of value stored in dict or 
array.😁
>
> In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?
Yes, you are right. I'll try fix it in another patch.
>
>
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>
>
> .

[PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.

The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.

This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.

In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library. 

---
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (11):
  telemetry: move to header to controllable range
  telemetry: add u32 value type
  test: add test cases for adding u32 value API
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: refactor mapping betwween value and array type
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer values API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 249 ++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c     |  23 ++-
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  14 +-
 lib/ethdev/rte_ethdev.c            |  13 +-
 lib/mempool/rte_mempool.c          |  24 +--
 lib/telemetry/rte_telemetry.h      | 112 ++++++++++++-
 lib/telemetry/telemetry.c          |  25 ++-
 lib/telemetry/telemetry_data.c     | 122 ++++++++++++--
 lib/telemetry/telemetry_data.h     |   2 +
 lib/telemetry/telemetry_json.h     |  29 ++++
 lib/telemetry/version.map          |  14 ++
 12 files changed, 581 insertions(+), 48 deletions(-)

-- 
2.33.0

[PATCH V3 01/11] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is uncontrollable. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V3 02/11] telemetry: add u32 value type

[Huisong Li]

Currently, 32-bit integer value only is signed in telemetry. The u32 data
can not be assigned to signed 32-bit integer. However, assigning to u64 is
very wasteful, after all, the buffer capacity of each transfer is limited.
So it is necessary for 'u32' data to add usigned 32-bit integer type and
container type.

Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 35 ++++++++++++++++++++++++
 lib/telemetry/telemetry.c      | 25 +++++++++++++++--
 lib/telemetry/telemetry_data.c | 50 ++++++++++++++++++++++++++++------
 lib/telemetry/telemetry_data.h |  2 ++
 lib/telemetry/telemetry_json.h | 29 ++++++++++++++++++++
 lib/telemetry/version.map      |  9 ++++++
 6 files changed, 140 insertions(+), 10 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..5efdafc156 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -44,6 +45,7 @@ enum rte_tel_value_type {
 	RTE_TEL_INT_VAL,    /** a signed 32-bit int value */
 	RTE_TEL_U64_VAL,    /** an unsigned 64-bit int value */
 	RTE_TEL_CONTAINER, /** a container struct */
+	RTE_TEL_U32_VAL,    /** an unsigned 32-bit int value */
 };
 
 /**
@@ -117,6 +119,21 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
 int
 rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
 
+/**
+ * Add a uint32_t to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_U32_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_u32(struct rte_tel_data *d, uint32_t x);
+
 /**
  * Add a uint64_t to an array.
  * The array must have been started by rte_tel_data_start_array() with
@@ -189,6 +206,24 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
 int
 rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
 
+/**
+ * Add a uint32_t value to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of name.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_u32(struct rte_tel_data *d,
+		const char *name, uint32_t val);
+
 /**
  * Add a uint64_t value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
index 8fbb4f3060..b52fcae713 100644
--- a/lib/telemetry/telemetry.c
+++ b/lib/telemetry/telemetry.c
@@ -167,8 +167,9 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 	size_t used = 0;
 	unsigned int i;
 
-	if (d->type != RTE_TEL_DICT && d->type != RTE_TEL_ARRAY_U64 &&
-		d->type != RTE_TEL_ARRAY_INT && d->type != RTE_TEL_ARRAY_STRING)
+	if (d->type != RTE_TEL_DICT && d->type != RTE_TEL_ARRAY_U32 &&
+	    d->type != RTE_TEL_ARRAY_U64 && d->type != RTE_TEL_ARRAY_INT &&
+	    d->type != RTE_TEL_ARRAY_STRING)
 		return snprintf(out_buf, buf_len, "null");
 
 	used = rte_tel_json_empty_array(out_buf, buf_len, 0);
@@ -177,6 +178,11 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 			used = rte_tel_json_add_array_u64(out_buf,
 				buf_len, used,
 				d->data.array[i].u64val);
+	if (d->type == RTE_TEL_ARRAY_U32)
+		for (i = 0; i < d->data_len; i++)
+			used = rte_tel_json_add_array_u32(out_buf,
+				buf_len, used,
+				d->data.array[i].u32val);
 	if (d->type == RTE_TEL_ARRAY_INT)
 		for (i = 0; i < d->data_len; i++)
 			used = rte_tel_json_add_array_int(out_buf,
@@ -201,6 +207,11 @@ container_to_json(const struct rte_tel_data *d, char *out_buf, size_t buf_len)
 						buf_len, used,
 						v->name, v->value.ival);
 				break;
+			case RTE_TEL_U32_VAL:
+				used = rte_tel_json_add_obj_u32(out_buf,
+						buf_len, used,
+						v->name, v->value.u32val);
+				break;
 			case RTE_TEL_U64_VAL:
 				used = rte_tel_json_add_obj_u64(out_buf,
 						buf_len, used,
@@ -268,6 +279,11 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 						buf_len, used,
 						v->name, v->value.ival);
 				break;
+			case RTE_TEL_U32_VAL:
+				used = rte_tel_json_add_obj_u32(cb_data_buf,
+						buf_len, used,
+						v->name, v->value.u32val);
+				break;
 			case RTE_TEL_U64_VAL:
 				used = rte_tel_json_add_obj_u64(cb_data_buf,
 						buf_len, used,
@@ -293,6 +309,7 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 
 	case RTE_TEL_ARRAY_STRING:
 	case RTE_TEL_ARRAY_INT:
+	case RTE_TEL_ARRAY_U32:
 	case RTE_TEL_ARRAY_U64:
 	case RTE_TEL_ARRAY_CONTAINER:
 		used = rte_tel_json_empty_array(cb_data_buf, buf_len, 0);
@@ -306,6 +323,10 @@ output_json(const char *cmd, const struct rte_tel_data *d, int s)
 				used = rte_tel_json_add_array_int(cb_data_buf,
 						buf_len, used,
 						d->data.array[i].ival);
+			else if (d->type == RTE_TEL_ARRAY_U32)
+				used = rte_tel_json_add_array_u32(cb_data_buf,
+						buf_len, used,
+						d->data.array[i].u32val);
 			else if (d->type == RTE_TEL_ARRAY_U64)
 				used = rte_tel_json_add_array_u64(cb_data_buf,
 						buf_len, used,
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..c120bf6281 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -18,8 +18,9 @@ rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 	enum tel_container_types array_types[] = {
 			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
 			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
-			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 2 */
+			RTE_TEL_ARRAY_U64,    /* RTE_TEL_U64_VAL = 2 */
 			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
+			RTE_TEL_ARRAY_U32, /* RTE_TEL_U32_VAL = 4 */
 	};
 	d->type = array_types[type];
 	d->data_len = 0;
@@ -69,6 +70,17 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
 	return 0;
 }
 
+int
+rte_tel_data_add_array_u32(struct rte_tel_data *d, uint32_t x)
+{
+	if (d->type != RTE_TEL_ARRAY_U32)
+		return -EINVAL;
+	if (d->data_len >= RTE_TEL_MAX_ARRAY_ENTRIES)
+		return -ENOSPC;
+	d->data.array[d->data_len++].u32val = x;
+	return 0;
+}
+
 int
 rte_tel_data_add_array_u64(struct rte_tel_data *d, uint64_t x)
 {
@@ -85,9 +97,10 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep)
 {
 	if (d->type != RTE_TEL_ARRAY_CONTAINER ||
-			(val->type != RTE_TEL_ARRAY_U64
-			&& val->type != RTE_TEL_ARRAY_INT
-			&& val->type != RTE_TEL_ARRAY_STRING))
+			(val->type != RTE_TEL_ARRAY_U32 &&
+			 val->type != RTE_TEL_ARRAY_U64 &&
+			 val->type != RTE_TEL_ARRAY_INT &&
+			 val->type != RTE_TEL_ARRAY_STRING))
 		return -EINVAL;
 	if (d->data_len >= RTE_TEL_MAX_ARRAY_ENTRIES)
 		return -ENOSPC;
@@ -159,6 +172,26 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_u32(struct rte_tel_data *d,
+		const char *name, uint32_t val)
+{
+	struct tel_dict_entry *e = &d->data.dict[d->data_len];
+	if (d->type != RTE_TEL_DICT)
+		return -EINVAL;
+	if (d->data_len >= RTE_TEL_MAX_DICT_ENTRIES)
+		return -ENOSPC;
+
+	if (!valid_name(name))
+		return -EINVAL;
+
+	d->data_len++;
+	e->type = RTE_TEL_U32_VAL;
+	e->value.u32val = val;
+	const size_t bytes = strlcpy(e->name, name, RTE_TEL_MAX_STRING_LEN);
+	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
+}
+
 int
 rte_tel_data_add_dict_u64(struct rte_tel_data *d,
 		const char *name, uint64_t val)
@@ -185,10 +218,11 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 {
 	struct tel_dict_entry *e = &d->data.dict[d->data_len];
 
-	if (d->type != RTE_TEL_DICT || (val->type != RTE_TEL_ARRAY_U64
-			&& val->type != RTE_TEL_ARRAY_INT
-			&& val->type != RTE_TEL_ARRAY_STRING
-			&& val->type != RTE_TEL_DICT))
+	if (d->type != RTE_TEL_DICT || (val->type != RTE_TEL_ARRAY_U32 &&
+					val->type != RTE_TEL_ARRAY_U64 &&
+					val->type != RTE_TEL_ARRAY_INT &&
+					val->type != RTE_TEL_ARRAY_STRING &&
+					val->type != RTE_TEL_DICT))
 		return -EINVAL;
 	if (d->data_len >= RTE_TEL_MAX_DICT_ENTRIES)
 		return -ENOSPC;
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 26aa28e72c..1455bf77d7 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -15,6 +15,7 @@ enum tel_container_types {
 	RTE_TEL_ARRAY_INT,    /** array of signed, 32-bit int values */
 	RTE_TEL_ARRAY_U64,    /** array of unsigned 64-bit int values */
 	RTE_TEL_ARRAY_CONTAINER, /** array of container structs */
+	RTE_TEL_ARRAY_U32,    /** array of unsigned 32-bit int values */
 };
 
 struct container {
@@ -29,6 +30,7 @@ struct container {
 union tel_value {
 	char sval[RTE_TEL_MAX_STRING_LEN];
 	int ival;
+	uint32_t u32val;
 	uint64_t u64val;
 	struct container container;
 };
diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
index e3fae7c30d..05762ec89a 100644
--- a/lib/telemetry/telemetry_json.h
+++ b/lib/telemetry/telemetry_json.h
@@ -146,6 +146,19 @@ rte_tel_json_add_array_int(char *buf, const int len, const int used, int val)
 	return ret == 0 ? used : end + ret;
 }
 
+/* Appends a uint32_t into the JSON array in the provided buffer. */
+static inline int
+rte_tel_json_add_array_u32(char *buf, const int len, const int used,
+		uint32_t val)
+{
+	int ret, end = used - 1; /* strip off final delimiter */
+	if (used <= 2) /* assume empty, since minimum is '[]' */
+		return __json_snprintf(buf, len, "[%u]", val);
+
+	ret = __json_snprintf(buf + end, len - end, ",%u]", val);
+	return ret == 0 ? used : end + ret;
+}
+
 /* Appends a uint64_t into the JSON array in the provided buffer. */
 static inline int
 rte_tel_json_add_array_u64(char *buf, const int len, const int used,
@@ -175,6 +188,22 @@ rte_tel_json_add_array_json(char *buf, const int len, const int used,
 	return ret == 0 ? used : end + ret;
 }
 
+/**
+ * Add a new element with uint32_t value to the JSON object stored in the
+ * provided buffer.
+ */
+static inline int
+rte_tel_json_add_obj_u32(char *buf, const int len, const int used,
+		const char *name, uint32_t val)
+{
+	int ret, end = used - 1;
+	if (used <= 2) /* assume empty, since minimum is '{}' */
+		return __json_snprintf(buf, len, "{\"%s\":%u}", name, val);
+
+	ret = __json_snprintf(buf + end, len - end, ",\"%s\":%u}", name, val);
+	return ret == 0 ? used : end + ret;
+}
+
 /**
  * Add a new element with uint64_t value to the JSON object stored in the
  * provided buffer.
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..3d1fb15637 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_u32;
+	rte_tel_data_add_dict_u32;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V3 03/11] test: add test cases for adding u32 value API

[Huisong Li]

Add test cases for adding u32 value API.

Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 app/test/test_telemetry_data.c | 85 +++++++++++++++++++++++++++++++++-
 app/test/test_telemetry_json.c | 23 ++++++++-
 2 files changed, 104 insertions(+), 4 deletions(-)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..8ab3441cbe 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -278,6 +278,17 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_case_array_u32(void)
+{
+	uint32_t i;
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_U32_VAL);
+	for (i = 0; i < 5; i++)
+		rte_tel_data_add_array_u32(&response_data, i);
+	return CHECK_OUTPUT("[0,1,2,3,4]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +300,21 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_add_dict_u32(void)
+{
+	uint32_t i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 5; i++) {
+		sprintf(name_of_value, "dict_%u", i);
+		rte_tel_data_add_dict_u32(&response_data, name_of_value, i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -304,6 +330,32 @@ test_case_add_dict_u64(void)
 	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
 }
 
+static int
+test_dict_with_array_u32_values(void)
+{
+	uint32_t i;
+
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_U32_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_U32_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 10; i++) {
+		rte_tel_data_add_array_u32(child_data, i);
+		rte_tel_data_add_array_u32(child_data2, i);
+	}
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[0,1,2,3,4,5,6,7,8,9],\"dict_1\":[0,1,2,3,4,5,6,7,8,9]}");
+}
+
 static int
 test_dict_with_array_u64_values(void)
 {
@@ -330,6 +382,29 @@ test_dict_with_array_u64_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[0,1,2,3,4,5,6,7,8,9],\"dict_1\":[0,1,2,3,4,5,6,7,8,9]}");
 }
 
+static int
+test_array_with_array_u32_values(void)
+{
+	uint32_t i;
+
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_U32_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_U32_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	for (i = 0; i < 5; i++) {
+		rte_tel_data_add_array_u32(child_data, i);
+		rte_tel_data_add_array_u32(child_data2, i);
+	}
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[0,1,2,3,4],[0,1,2,3,4]]");
+}
+
 static int
 test_array_with_array_u64_values(void)
 {
@@ -428,14 +503,20 @@ telemetry_data_autotest(void)
 			test_null_return,
 			test_simple_string,
 			test_case_array_string,
-			test_case_array_int, test_case_array_u64,
-			test_case_add_dict_int, test_case_add_dict_u64,
+			test_case_array_int,
+			test_case_array_u32,
+			test_case_array_u64,
+			test_case_add_dict_int,
+			test_case_add_dict_u32,
+			test_case_add_dict_u64,
 			test_case_add_dict_string,
 			test_dict_with_array_int_values,
+			test_dict_with_array_u32_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
+			test_array_with_array_u32_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
 			test_string_char_escaping,
diff --git a/app/test/test_telemetry_json.c b/app/test/test_telemetry_json.c
index 184c3ba9f1..e25442f8f0 100644
--- a/app/test/test_telemetry_json.c
+++ b/app/test/test_telemetry_json.c
@@ -31,7 +31,25 @@ test_basic_array(void)
 }
 
 static int
-test_basic_obj(void)
+test_basic_obj_u32(void)
+{
+	const char *expected = "{\"weddings\":4,\"funerals\":1}";
+	char buf[1024];
+	int used = 0;
+
+	used = rte_tel_json_add_obj_u32(buf, sizeof(buf), used,
+		"weddings", 4);
+	used = rte_tel_json_add_obj_u32(buf, sizeof(buf), used,
+		"funerals", 1);
+
+	printf("%s: buf = '%s', expected = '%s'\n", __func__, buf, expected);
+	if (used != (int)strlen(expected))
+		return -1;
+	return strncmp(expected, buf, sizeof(buf));
+}
+
+static int
+test_basic_obj_u64(void)
 {
 	const char *expected = "{\"weddings\":4,\"funerals\":1}";
 	char buf[1024];
@@ -195,7 +213,8 @@ test_telemetry_json(void)
 	unsigned int i;
 	test_fn fns[] = {
 			test_basic_array,
-			test_basic_obj,
+			test_basic_obj_u32,
+			test_basic_obj_u64,
 			test_overflow_array,
 			test_overflow_obj,
 			test_large_array_element,
-- 
2.33.0

[PATCH V3 04/11] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..dfb269970e 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u32(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u32(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V3 05/11] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..c665fa5e14 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u32(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u32(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u32(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u32(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u32(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u32(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u32(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u32(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u32(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V3 06/11] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data need
to use the 'u32' telemetry API to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..8e19411164 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u32(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V3 07/11] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
data need to use the 'u32' telemetry API to add, and the 'u64' data need to
use the 'u64' telemetry API to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..b7981507da 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u32(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1148,8 +1148,8 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 				  sock_stats.heap_allocsz_bytes);
 	rte_tel_data_add_dict_u64(d, "Greatest_free_size",
 				  sock_stats.greatest_free_size);
-	rte_tel_data_add_dict_u64(d, "Alloc_count", sock_stats.alloc_count);
-	rte_tel_data_add_dict_u64(d, "Free_count", sock_stats.free_count);
+	rte_tel_data_add_dict_u32(d, "Alloc_count", sock_stats.alloc_count);
+	rte_tel_data_add_dict_u32(d, "Free_count", sock_stats.free_count);
 
 	return 0;
 }
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u32(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u32(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V3 08/11] telemetry: refactor mapping betwween value and array type

[Huisong Li]

Currently, use rte_tel_value_type as index of array to find the
tel_container_types in rte_tel_data_start_array. It's not good
for maintenance.

Fixes: ed1bfad7d384 ("telemetry: add functions for returning callback data")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/telemetry_data.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index c120bf6281..f8efc37763 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -15,14 +15,30 @@
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
-	enum tel_container_types array_types[] = {
-			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
-			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
-			RTE_TEL_ARRAY_U64,    /* RTE_TEL_U64_VAL = 2 */
-			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
-			RTE_TEL_ARRAY_U32, /* RTE_TEL_U32_VAL = 4 */
+	struct {
+		enum rte_tel_value_type value_type;
+		enum tel_container_types array_type;
+	} value2array_types_map[] = {
+		{RTE_TEL_STRING_VAL, RTE_TEL_ARRAY_STRING},
+		{RTE_TEL_INT_VAL,    RTE_TEL_ARRAY_INT},
+		{RTE_TEL_U64_VAL,    RTE_TEL_ARRAY_U64},
+		{RTE_TEL_CONTAINER,  RTE_TEL_ARRAY_CONTAINER},
+		{RTE_TEL_U32_VAL,  RTE_TEL_ARRAY_U32},
 	};
-	d->type = array_types[type];
+	int array_types = -1;
+	uint16_t i;
+
+	for (i = 0; i < RTE_DIM(value2array_types_map); i++) {
+		if (type == value2array_types_map[i].value_type) {
+			array_types = value2array_types_map[i].array_type;
+			break;
+		}
+	}
+
+	if (array_types  == -1)
+		return -EINVAL;
+
+	d->type = array_types;
 	d->data_len = 0;
 	return 0;
 }
-- 
2.33.0

[PATCH V3 09/11] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a integer value as hexadecimal encoded style is
more expected for human consumption, such as, offload capability and
device flag. This patch introduces some APIs to add 'u32' and 'u64'
value as hexadecimal encoded string to array or dictionary.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 72 ++++++++++++++++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 46 ++++++++++++++++++++++
 lib/telemetry/version.map      |  5 +++
 3 files changed, 123 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 5efdafc156..dac87050da 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -170,6 +170,38 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a uint32_t to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_hex_u32_str(struct rte_tel_data *d, uint32_t x);
+
+/**
+ * Convert a uint64_t to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param x
+ *   The number to be returned in the array as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_hex_u64_str(struct rte_tel_data *d, uint64_t x);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -266,6 +298,46 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a uint32_t to hexadecimal encoded strings and add this string
+ * to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of
+ *   either name or value.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_hex_u32_str(struct rte_tel_data *d,
+				      const char *name, uint32_t val);
+
+/**
+ * Convert a uint64_t to hexadecimal encoded strings and add this string
+ * to a dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name the value is to be stored under in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings
+ * @return
+ *   0 on success, negative errno on error, E2BIG on string truncation of
+ *   either name or value.
+ */
+__rte_experimental
+int rte_tel_data_add_dict_hex_u64_str(struct rte_tel_data *d,
+				      const char *name, uint64_t val);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index f8efc37763..b195b79fa4 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,9 @@
 
 #include "telemetry_data.h"
 
+/* The string length is equal to (sizeof(uint64_t) * 2 + 3) */
+#define RTE_TEL_HEX_UINT_MAX_STRING_LEN 19
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -126,6 +130,26 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+int
+rte_tel_data_add_array_hex_u32_str(struct rte_tel_data *d, uint32_t x)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%x", x);
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
+int
+rte_tel_data_add_array_hex_u64_str(struct rte_tel_data *d, uint64_t x)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%"PRIx64"", x);
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -254,6 +278,28 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_hex_u32_str(struct rte_tel_data *d, const char *name,
+				  uint32_t val)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%x", val);
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
+int
+rte_tel_data_add_dict_hex_u64_str(struct rte_tel_data *d, const char *name,
+				  uint64_t val)
+{
+	char hex_str[RTE_TEL_HEX_UINT_MAX_STRING_LEN];
+
+	snprintf(hex_str, RTE_TEL_HEX_UINT_MAX_STRING_LEN, "0x%"PRIx64"", val);
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 3d1fb15637..994414c47f 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -3,6 +3,11 @@ EXPERIMENTAL {
 
 	rte_tel_data_add_array_u32;
 	rte_tel_data_add_dict_u32;
+	rte_tel_data_add_array_hex_u32_str;
+	rte_tel_data_add_array_hex_u64_str;
+	rte_tel_data_add_dict_hex_u32_str;
+	rte_tel_data_add_dict_hex_u64_str;
+
 
 	local: *;
 };
-- 
2.33.0

[PATCH V3 10/11] test: add test cases for adding hex integer values API

[Huisong Li]

Add test cases for adding hexadecimal u32 and u64 values API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 app/test/test_telemetry_data.c | 164 +++++++++++++++++++++++++++++++++
 1 file changed, 164 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index 8ab3441cbe..7ce905c503 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -278,6 +278,89 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_case_array_with_array_hex_u32_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff1);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffff0\",\"0xfffffff1\"],[\"0x8ffff2\"]]");
+}
+
+static int
+test_case_array_with_array_hex_u64_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff0);
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffffffffffff0\",\"0xfffffffffffffff2\"]]");
+}
+
+static int
+test_case_dict_with_array_hex_u32_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff1);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffffff1);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0xfffffff0\",\"0xfffffff1\"],\"dict_1\":[\"0x8ffffff0\",\"0x8ffffff1\"]}");
+}
+
+static int
+test_case_dict_with_array_hex_u64_values(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff0);
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff1);
+	rte_tel_data_add_array_hex_u64_str(child_data2, 0x8ffffffffffffff0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+	 child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+	 child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0xfffffffffffffff0\",\"0xfffffffffffffff1\"],\"dict_1\":[\"0x8ffffffffffffff0\"]}");
+}
+
 static int
 test_case_array_u32(void)
 {
@@ -300,6 +383,47 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_hex_u32_str(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff0);
+	rte_tel_data_add_array_hex_u32_str(child_data, 0xfffffff1);
+	rte_tel_data_add_array_hex_u32_str(child_data2, 0x8ffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffff0\",\"0xfffffff1\"],[\"0x8ffff2\"]]");
+}
+
+static int
+test_case_array_hex_u64_str(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_hex_u64_str(child_data, 0xfffffffffffffff0);
+	rte_tel_data_add_array_hex_u64_str(child_data2, 0x8ffffffffff2);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0xfffffffffffffff0\"],[\"0x8ffffffffff2\"]]");
+}
+
 static int
 test_case_add_dict_u32(void)
 {
@@ -330,6 +454,38 @@ test_case_add_dict_u64(void)
 	return CHECK_OUTPUT("{\"dict_0\":0,\"dict_1\":1,\"dict_2\":2,\"dict_3\":3,\"dict_4\":4}");
 }
 
+static int
+test_case_add_dict_hex_u32_values(void)
+{
+	int i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 3; i++) {
+		sprintf(name_of_value, "dict_%d", i);
+		rte_tel_data_add_dict_hex_u32_str(&response_data, name_of_value,
+						  0xfffffff0 + i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":\"0xfffffff0\",\"dict_1\":\"0xfffffff1\",\"dict_2\":\"0xfffffff2\"}");
+}
+
+static int
+test_case_add_dict_hex_u64_values(void)
+{
+	int i = 0;
+	char name_of_value[8];
+
+	rte_tel_data_start_dict(&response_data);
+
+	for (i = 0; i < 2; i++) {
+		sprintf(name_of_value, "dict_%d", i);
+		rte_tel_data_add_dict_hex_u64_str(&response_data, name_of_value,
+						  0xfffffffff0 + i);
+	}
+	return CHECK_OUTPUT("{\"dict_0\":\"0xfffffffff0\",\"dict_1\":\"0xfffffffff1\"}");
+}
+
 static int
 test_dict_with_array_u32_values(void)
 {
@@ -509,16 +665,24 @@ telemetry_data_autotest(void)
 			test_case_add_dict_int,
 			test_case_add_dict_u32,
 			test_case_add_dict_u64,
+			test_case_array_hex_u32_str,
+			test_case_array_hex_u64_str,
 			test_case_add_dict_string,
+			test_case_add_dict_hex_u32_values,
+			test_case_add_dict_hex_u64_values,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u32_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_case_dict_with_array_hex_u32_values,
+			test_case_dict_with_array_hex_u64_values,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u32_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_case_array_with_array_hex_u32_values,
+			test_case_array_with_array_hex_u64_values,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V3 11/11] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index dfb269970e..f0fa00c773 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,12 +6068,13 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u32(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
+	rte_tel_data_add_dict_hex_u32_str(d, "dev_flags",
+			eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_hex_u64_str(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
+	rte_tel_data_add_dict_hex_u64_str(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_hex_u64_str(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Bruce Richardson]

On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion error
> or data truncation.
> 
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of each
> transfer is limited. So it is necessary for 'u32' data to add usigned
> 32-bit integer type and a series of 'u32' operation APIs.
> 
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
> 
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library. 
> 
> --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI break
> warning.  - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings. 
>
I'm not convinced about adding the u32 value generically to the telemetry
lib - except in the case of having explicit function calls for u32 vs u64
hex strings. Having a u32 type doesn't gain us any space internally over a
u64 value, since all values are in a union type. Also, for output as json,
the numeric values are all output as decimal values, meaning that the value
1 appears as the same size in the output string whether it is a u32 or u64
type. Now, it may save space in a future binary output format, but even
then it still may not do so.

Therefore, I'd tend to keep the existing u64 type as-is, and instead only
add the functions for outputting hex values. Those hex output functions
could take an additional parameter indicating the desired hex output
length, as there could well be cases where we want just 16-bit hex value
too.

/Bruce

RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 11.32
> 
> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > rte_tel_data_add_dict/array_int API. This may cause data conversion
> error
> > or data truncation.
> >
> > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > assigning to u64 is very wasteful, after all, the buffer capacity of
> each
> > transfer is limited. So it is necessary for 'u32' data to add usigned
> > 32-bit integer type and a series of 'u32' operation APIs.
> >
> > This patchset uses the new 'u32' API to resolve the problem of data
> > conversion error, and use the 'u64' API to add 'u64' data.
> >
> > In addition, this patchset introduces two APIs to store u32 and u64
> > values as hexadecimal encoded strings in telemetry library.
> >
> > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> break
> > warning.  - introduce two APIs to store u32 and u64 values as
> hexadecimal
> > encoded strings.
> >
> I'm not convinced about adding the u32 value generically to the
> telemetry
> lib - except in the case of having explicit function calls for u32 vs
> u64
> hex strings. Having a u32 type doesn't gain us any space internally
> over a
> u64 value, since all values are in a union type. Also, for output as
> json,
> the numeric values are all output as decimal values, meaning that the
> value
> 1 appears as the same size in the output string whether it is a u32 or
> u64
> type. Now, it may save space in a future binary output format, but even
> then it still may not do so.

I agree that a u32 doesn't gain any space internally.

However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.

So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.

Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.

> 
> Therefore, I'd tend to keep the existing u64 type as-is, and instead
> only
> add the functions for outputting hex values. Those hex output functions
> could take an additional parameter indicating the desired hex output
> length, as there could well be cases where we want just 16-bit hex
> value
> too.

The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.

So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.

Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.

Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Bruce Richardson]

On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 11.32
> > 
> > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > rte_tel_data_add_dict/array_int API. This may cause data conversion
> > error
> > > or data truncation.
> > >
> > > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > > assigning to u64 is very wasteful, after all, the buffer capacity of
> > each
> > > transfer is limited. So it is necessary for 'u32' data to add usigned
> > > 32-bit integer type and a series of 'u32' operation APIs.
> > >
> > > This patchset uses the new 'u32' API to resolve the problem of data
> > > conversion error, and use the 'u64' API to add 'u64' data.
> > >
> > > In addition, this patchset introduces two APIs to store u32 and u64
> > > values as hexadecimal encoded strings in telemetry library.
> > >
> > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > break
> > > warning.  - introduce two APIs to store u32 and u64 values as
> > hexadecimal
> > > encoded strings.
> > >
> > I'm not convinced about adding the u32 value generically to the
> > telemetry
> > lib - except in the case of having explicit function calls for u32 vs
> > u64
> > hex strings. Having a u32 type doesn't gain us any space internally
> > over a
> > u64 value, since all values are in a union type. Also, for output as
> > json,
> > the numeric values are all output as decimal values, meaning that the
> > value
> > 1 appears as the same size in the output string whether it is a u32 or
> > u64
> > type. Now, it may save space in a future binary output format, but even
> > then it still may not do so.
> 
> I agree that a u32 doesn't gain any space internally.
> 
> However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.
> 
> So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.
> 
> Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.
> 

I think just using the u64 functions is probably simplest and best right
now. If we add support for something like snmp then yes, it would make
sense to explicitly add it, but it seems like a lot of extra code for
little or no benefit until we support something like that.

> > 
> > Therefore, I'd tend to keep the existing u64 type as-is, and instead
> > only
> > add the functions for outputting hex values. Those hex output functions
> > could take an additional parameter indicating the desired hex output
> > length, as there could well be cases where we want just 16-bit hex
> > value
> > too.
> 
> The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> 
> So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.
> 
> Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.
> 

+1 to having only a single hex function, and I think type promotion should
work fine.

However, I still think it might be worthwhile allowing the user to pass in
a min output length parameter too. I find for many hex strings having the
leading zeros to explicitly show the length can be useful. The value "0"
could cover the current behaviour of no-padding, otherwise the parameter
should indicate the number of bits to be displayed. (If we want to lock it
down we can use an enum parameter rather than int to limit it to 0, 8, 16,
32 or 64 bit displayed values).

All that said, I'm not massively concerned if we want to just keep the
current approach of always just printing without any leading zeros. It's a
nice-to-have only for me.

/Bruce

RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 12.21
> 
> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 11.32
> > >
> > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > rte_tel_data_add_dict/array_int API. This may cause data
> conversion
> > > error
> > > > or data truncation.
> > > >
> > > > The 'u32' data can not be assigned to signed 32-bit integer.
> However,
> > > > assigning to u64 is very wasteful, after all, the buffer capacity
> of
> > > each
> > > > transfer is limited. So it is necessary for 'u32' data to add
> usigned
> > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > >
> > > > This patchset uses the new 'u32' API to resolve the problem of
> data
> > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > >
> > > > In addition, this patchset introduces two APIs to store u32 and
> u64
> > > > values as hexadecimal encoded strings in telemetry library.
> > > >
> > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > > break
> > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > hexadecimal
> > > > encoded strings.
> > > >
> > > I'm not convinced about adding the u32 value generically to the
> > > telemetry
> > > lib - except in the case of having explicit function calls for u32
> vs
> > > u64
> > > hex strings. Having a u32 type doesn't gain us any space internally
> > > over a
> > > u64 value, since all values are in a union type. Also, for output
> as
> > > json,
> > > the numeric values are all output as decimal values, meaning that
> the
> > > value
> > > 1 appears as the same size in the output string whether it is a u32
> or
> > > u64
> > > type. Now, it may save space in a future binary output format, but
> even
> > > then it still may not do so.
> >
> > I agree that a u32 doesn't gain any space internally.
> >
> > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> around as such.
> >
> > So I suppose the u32 type might be useful for SNMP, if obtained
> through the telemetry library.
> >
> > Alternatively, we could somehow reuse the u64 type and require the
> application to pass (value & UINT32_MAX) to the u64 functions. To make
> this easy to use, we should add some wrappers to do it for the
> application. And eventually we would probably end up with something
> very similar to this patch.
> >
> 
> I think just using the u64 functions is probably simplest and best
> right
> now. If we add support for something like snmp then yes, it would make
> sense to explicitly add it, but it seems like a lot of extra code for
> little or no benefit until we support something like that.

<rant>
If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
</rant>

I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.

> 
> > >
> > > Therefore, I'd tend to keep the existing u64 type as-is, and
> instead
> > > only
> > > add the functions for outputting hex values. Those hex output
> functions
> > > could take an additional parameter indicating the desired hex
> output
> > > length, as there could well be cases where we want just 16-bit hex
> > > value
> > > too.
> >
> > The way I read the patch series, the hex output length is not fixed,
> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> >
> > So the only benefit of having both u32_hex and u64_hex functions is
> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> values.
> >
> > Instead of passing a 3rd parameter or adding u16_hex functions, we
> could consider just having one set of hex functions using uint64_t for
> the value, and rely on type promotion for 32 and 16 bit values.
> >
> 
> +1 to having only a single hex function, and I think type promotion
> should
> work fine.
> 
> However, I still think it might be worthwhile allowing the user to pass
> in
> a min output length parameter too. I find for many hex strings having
> the
> leading zeros to explicitly show the length can be useful. The value
> "0"
> could cover the current behaviour of no-padding, otherwise the
> parameter
> should indicate the number of bits to be displayed. (If we want to lock
> it
> down we can use an enum parameter rather than int to limit it to 0, 8,
> 16,
> 32 or 64 bit displayed values).

An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.

(I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)

Something like this:

char str[64]; // Big enough length.
if (bits != 0) {
  char format[16]; // Big enough length.
  sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
  sprintf(str, format, value);
} else {
  sprintf(str, "0x%" PRIx64, value);
}

> 
> All that said, I'm not massively concerned if we want to just keep the
> current approach of always just printing without any leading zeros.
> It's a
> nice-to-have only for me.
> 
> /Bruce

Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Bruce Richardson]

On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 12.21
> > 
> > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Monday, 12 December 2022 11.32
> > > >
> > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > conversion
> > > > error
> > > > > or data truncation.
> > > > >
> > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > However,
> > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > of
> > > > each
> > > > > transfer is limited. So it is necessary for 'u32' data to add
> > usigned
> > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > >
> > > > > This patchset uses the new 'u32' API to resolve the problem of
> > data
> > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > >
> > > > > In addition, this patchset introduces two APIs to store u32 and
> > u64
> > > > > values as hexadecimal encoded strings in telemetry library.
> > > > >
> > > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > > > break
> > > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > > hexadecimal
> > > > > encoded strings.
> > > > >
> > > > I'm not convinced about adding the u32 value generically to the
> > > > telemetry
> > > > lib - except in the case of having explicit function calls for u32
> > vs
> > > > u64
> > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > over a
> > > > u64 value, since all values are in a union type. Also, for output
> > as
> > > > json,
> > > > the numeric values are all output as decimal values, meaning that
> > the
> > > > value
> > > > 1 appears as the same size in the output string whether it is a u32
> > or
> > > > u64
> > > > type. Now, it may save space in a future binary output format, but
> > even
> > > > then it still may not do so.
> > >
> > > I agree that a u32 doesn't gain any space internally.
> > >
> > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > around as such.
> > >
> > > So I suppose the u32 type might be useful for SNMP, if obtained
> > through the telemetry library.
> > >
> > > Alternatively, we could somehow reuse the u64 type and require the
> > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > this easy to use, we should add some wrappers to do it for the
> > application. And eventually we would probably end up with something
> > very similar to this patch.
> > >
> > 
> > I think just using the u64 functions is probably simplest and best
> > right
> > now. If we add support for something like snmp then yes, it would make
> > sense to explicitly add it, but it seems like a lot of extra code for
> > little or no benefit until we support something like that.
> 
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>

Yes, not making "int" an "i64" type was a poor design decision on my part
in the earlier versions. Thankfully negative values are rarely needed
beyond the range of 32-bits, but we should probably look to update this as
you suggest at the next ABI break window.

> 
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
> 
> > 
> > > >
> > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > instead
> > > > only
> > > > add the functions for outputting hex values. Those hex output
> > functions
> > > > could take an additional parameter indicating the desired hex
> > output
> > > > length, as there could well be cases where we want just 16-bit hex
> > > > value
> > > > too.
> > >
> > > The way I read the patch series, the hex output length is not fixed,
> > but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> > >
> > > So the only benefit of having both u32_hex and u64_hex functions is
> > to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> > values.
> > >
> > > Instead of passing a 3rd parameter or adding u16_hex functions, we
> > could consider just having one set of hex functions using uint64_t for
> > the value, and rely on type promotion for 32 and 16 bit values.
> > >
> > 
> > +1 to having only a single hex function, and I think type promotion
> > should
> > work fine.
> > 
> > However, I still think it might be worthwhile allowing the user to pass
> > in
> > a min output length parameter too. I find for many hex strings having
> > the
> > leading zeros to explicitly show the length can be useful. The value
> > "0"
> > could cover the current behaviour of no-padding, otherwise the
> > parameter
> > should indicate the number of bits to be displayed. (If we want to lock
> > it
> > down we can use an enum parameter rather than int to limit it to 0, 8,
> > 16,
> > 32 or 64 bit displayed values).
> 
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
> 
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
> 
> Something like this:
> 
> char str[64]; // Big enough length.
> if (bits != 0) {
>   char format[16]; // Big enough length.
>   sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
>   sprintf(str, format, value);
> } else {
>   sprintf(str, "0x%" PRIx64, value);
> }
> 

LGTM.

Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[lihuisong (C)]

在 2022/12/12 20:03, Morten Brørup 写道:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Monday, 12 December 2022 12.21
>>
>> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>>> Sent: Monday, 12 December 2022 11.32
>>>>
>>>> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
>>>>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>>>>> rte_tel_data_add_dict/array_int API. This may cause data
>> conversion
>>>> error
>>>>> or data truncation.
>>>>>
>>>>> The 'u32' data can not be assigned to signed 32-bit integer.
>> However,
>>>>> assigning to u64 is very wasteful, after all, the buffer capacity
>> of
>>>> each
>>>>> transfer is limited. So it is necessary for 'u32' data to add
>> usigned
>>>>> 32-bit integer type and a series of 'u32' operation APIs.
>>>>>
>>>>> This patchset uses the new 'u32' API to resolve the problem of
>> data
>>>>> conversion error, and use the 'u64' API to add 'u64' data.
>>>>>
>>>>> In addition, this patchset introduces two APIs to store u32 and
>> u64
>>>>> values as hexadecimal encoded strings in telemetry library.
>>>>>
>>>>> --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
>>>> break
>>>>> warning.  - introduce two APIs to store u32 and u64 values as
>>>> hexadecimal
>>>>> encoded strings.
>>>>>
>>>> I'm not convinced about adding the u32 value generically to the
>>>> telemetry
>>>> lib - except in the case of having explicit function calls for u32
>> vs
>>>> u64
>>>> hex strings. Having a u32 type doesn't gain us any space internally
>>>> over a
>>>> u64 value, since all values are in a union type. Also, for output
>> as
>>>> json,
>>>> the numeric values are all output as decimal values, meaning that
>> the
>>>> value
>>>> 1 appears as the same size in the output string whether it is a u32
>> or
>>>> u64
>>>> type. Now, it may save space in a future binary output format, but
>> even
>>>> then it still may not do so.
>>> I agree that a u32 doesn't gain any space internally.
>>>
>>> However, many SNMP counters are unsigned 32 bit, and expected to wrap
>> around as such.
>>> So I suppose the u32 type might be useful for SNMP, if obtained
>> through the telemetry library.
>>> Alternatively, we could somehow reuse the u64 type and require the
>> application to pass (value & UINT32_MAX) to the u64 functions. To make
>> this easy to use, we should add some wrappers to do it for the
>> application. And eventually we would probably end up with something
>> very similar to this patch.
>> I think just using the u64 functions is probably simplest and best
>> right
>> now. If we add support for something like snmp then yes, it would make
>> sense to explicitly add it, but it seems like a lot of extra code for
>> little or no benefit until we support something like that.
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>
>
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
All right. Let's drop the new u32 functions.
>
>>>> Therefore, I'd tend to keep the existing u64 type as-is, and
>> instead
>>>> only
>>>> add the functions for outputting hex values. Those hex output
>> functions
>>>> could take an additional parameter indicating the desired hex
>> output
>>>> length, as there could well be cases where we want just 16-bit hex
>>>> value
>>>> too.
>>> The way I read the patch series, the hex output length is not fixed,
>> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
>>> So the only benefit of having both u32_hex and u64_hex functions is
>> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
>> values.
>>> Instead of passing a 3rd parameter or adding u16_hex functions, we
>> could consider just having one set of hex functions using uint64_t for
>> the value, and rely on type promotion for 32 and 16 bit values.
>> +1 to having only a single hex function, and I think type promotion
>> should
>> work fine.
>>
>> However, I still think it might be worthwhile allowing the user to pass
>> in
>> a min output length parameter too. I find for many hex strings having
>> the
>> leading zeros to explicitly show the length can be useful. The value
>> "0"
>> could cover the current behaviour of no-padding, otherwise the
>> parameter
>> should indicate the number of bits to be displayed. (If we want to lock
>> it
>> down we can use an enum parameter rather than int to limit it to 0, 8,
>> 16,
>> 32 or 64 bit displayed values).
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
>
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
>
> Something like this:
>
> char str[64]; // Big enough length.
> if (bits != 0) {
>    char format[16]; // Big enough length.
>    sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
>    sprintf(str, format, value);
> } else {
>    sprintf(str, "0x%" PRIx64, value);
> }
Fix it in v4.
>> All that said, I'm not massively concerned if we want to just keep the
>> current approach of always just printing without any leading zeros.
>> It's a
>> nice-to-have only for me.
>>
>> /Bruce
>
> .

[PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (9):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: refactor mapping between value and array type
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 158 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  55 +++++++++-
 lib/telemetry/telemetry_data.c     |  86 ++++++++++++++--
 lib/telemetry/version.map          |   9 ++
 8 files changed, 327 insertions(+), 36 deletions(-)

-- 
2.33.0

[PATCH V4 1/9] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is uncontrollable. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V4 2/9] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' datas can not assigned to 'int' type variable.
The 'u32' and 'u64' datas need to use the 'u64' APIs to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..a40d396677 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V4 3/9] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
and 'u64' datas need to use the 'u64' APIs to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..950d01ffac 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u64(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u64(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u64(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u64(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u64(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u64(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u64(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u64(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u64(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V4 4/9] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data
needs to use the 'u64' APIs to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..515d0df5ce 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u64(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V4 5/9] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable. The 'u32'
and 'u64' datas need to use the 'u64' APIs to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..8e427bf4b4 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V4 6/9] telemetry: refactor mapping between value and array type

[Huisong Li]

Currently, use rte_tel_value_type as index of array to find the
tel_container_types in rte_tel_data_start_array. It's not good
for maintenance.

Fixes: ed1bfad7d384 ("telemetry: add functions for returning callback data")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++++++------
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..080d99aec9 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -15,13 +15,29 @@
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
-	enum tel_container_types array_types[] = {
-			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
-			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
-			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 2 */
-			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
+	struct {
+		enum rte_tel_value_type value_type;
+		enum tel_container_types array_type;
+	} value2array_types_map[] = {
+		{RTE_TEL_STRING_VAL, RTE_TEL_ARRAY_STRING},
+		{RTE_TEL_INT_VAL,    RTE_TEL_ARRAY_INT},
+		{RTE_TEL_U64_VAL,    RTE_TEL_ARRAY_U64},
+		{RTE_TEL_CONTAINER,  RTE_TEL_ARRAY_CONTAINER},
 	};
-	d->type = array_types[type];
+	int array_types = -1;
+	uint16_t i;
+
+	for (i = 0; i < RTE_DIM(value2array_types_map); i++) {
+		if (type == value2array_types_map[i].value_type) {
+			array_types = value2array_types_map[i].array_type;
+			break;
+		}
+	}
+
+	if (array_types == -1)
+		return -EINVAL;
+
+	d->type = array_types;
 	d->data_len = 0;
 	return 0;
 }
-- 
2.33.0

[PATCH V4 7/9] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a unsigned integer value as hexadecimal encoded style
is more expected for human consumption, such as, offload capability and
device flag. This patch introduces two APIs to add unsigned integer (can be
one of uint8_t, uint16_t, uint32_t and uint64_t type) value as hexadecimal
encoded string to array or dictionary. If the 'val_bits' is zero, the value
is stored as hexadecimal encoded string without padding zero.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 50 +++++++++++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 58 ++++++++++++++++++++++++++++++++++
 lib/telemetry/version.map      |  9 ++++++
 3 files changed, 117 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..88b34097b0 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -20,6 +21,11 @@ extern "C" {
 /** Maximum number of array entries. */
 #define RTE_TEL_MAX_ARRAY_ENTRIES 512
 
+#define RTE_TEL_U8_BITS  8
+#define RTE_TEL_U16_BITS 16
+#define RTE_TEL_U32_BITS 32
+#define RTE_TEL_U64_BITS 64
+
 /**
  * @file
  *
@@ -153,6 +159,27 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param val
+ *   The number to be returned in the array as a hexadecimal encoded strings.
+ *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t and uint64_t.
+ * @param val_bits
+ *   The total bits of the input 'val'. If val_bits is zero, the value is stored
+ *   in the array as hexadecimal encoded string without padding zero.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				    uint16_t val_bits);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -231,6 +258,29 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name of the value is to be stored in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings.
+ *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t and uint64_t.
+ * @param val_bits
+ *   The total bits of the input 'val'. If val_bits is zero, the value is stored
+ *   in the array as hexadecimal encoded string without padding zero.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+				   uint64_t val, uint16_t val_bits);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 080d99aec9..fb2f711d99 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,9 @@
 
 #include "telemetry_data.h"
 
+#define RTE_TEL_UINT_HEX_STRING_BUFFER_LEN 64
+#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -113,6 +117,33 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint16_t val_bits)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
+
+	switch (val_bits) {
+	case RTE_TEL_U8_BITS:
+		sprintf(hex_str, "0x%02"PRIx64"", val);
+		break;
+	case RTE_TEL_U16_BITS:
+		sprintf(hex_str, "0x%04"PRIx64"", val);
+		break;
+	case RTE_TEL_U32_BITS:
+		sprintf(hex_str, "0x%08"PRIx64"", val);
+		break;
+	case RTE_TEL_U64_BITS:
+		sprintf(hex_str, "0x%016"PRIx64"", val);
+		break;
+	default:
+		sprintf(hex_str, "0x%"PRIx64"", val);
+		break;
+	}
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -220,6 +251,33 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint16_t val_bits)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
+
+	switch (val_bits) {
+	case RTE_TEL_U8_BITS:
+		sprintf(hex_str, "0x%02"PRIx64"", val);
+		break;
+	case RTE_TEL_U16_BITS:
+		sprintf(hex_str, "0x%04"PRIx64"", val);
+		break;
+	case RTE_TEL_U32_BITS:
+		sprintf(hex_str, "0x%08"PRIx64"", val);
+		break;
+	case RTE_TEL_U64_BITS:
+		sprintf(hex_str, "0x%016"PRIx64"", val);
+		break;
+	default:
+		sprintf(hex_str, "0x%"PRIx64"", val);
+		break;
+	}
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..951bd63974 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_uint_hex;
+	rte_tel_data_add_dict_uint_hex;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V4 8/9] test: add test cases for adding hex integer value API

[Huisong Li]

Add test cases for adding hexadecimal unsigned integer value API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 app/test/test_telemetry_data.c | 158 +++++++++++++++++++++++++++++++++
 1 file changed, 158 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..1fd79d66e2 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -209,6 +209,39 @@ test_case_add_dict_string(void)
 	return CHECK_OUTPUT("{\"dict_0\":\"aaaa\",\"dict_1\":\"bbbb\",\"dict_2\":\"cccc\",\"dict_3\":\"dddd\"}");
 }
 
+static int
+test_case_add_dict_uint_hex_padding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, RTE_TEL_U8_BITS);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, RTE_TEL_U16_BITS);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, RTE_TEL_U32_BITS);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, RTE_TEL_U64_BITS);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x08\",\"dict_1\":\"0x0088\",\"dict_2\":\"0x00000888\",\"dict_3\":\"0x0000000000008888\"}");
+}
+
+static int
+test_case_add_dict_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x8\",\"dict_1\":\"0x88\",\"dict_2\":\"0x888\",\"dict_3\":\"0x8888\"}");
+}
 
 static int
 test_dict_with_array_string_values(void)
@@ -232,6 +265,52 @@ test_dict_with_array_string_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[\"aaaa\"],\"dict_1\":[\"bbbb\"]}");
 }
 
+static int
+test_dict_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data,
+					(uint32_t)0x888, RTE_TEL_U32_BITS);
+	rte_tel_data_add_array_uint_hex(child_data2,
+					(uint64_t)0x8888, RTE_TEL_U64_BITS);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x00000888\"],\"dict_1\":[\"0x0000000000008888\"]}");
+}
+
+static int
+test_dict_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x888\"],\"dict_1\":[\"0x8888\"]}");
+}
+
 static int
 test_dict_with_dict_values(void)
 {
@@ -278,6 +357,49 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_array_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888,
+					RTE_TEL_U32_BITS);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888,
+					RTE_TEL_U64_BITS);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x00000888\"],[\"0x0000000000008888\"]]");
+}
+
+
+static int
+test_array_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x888\"],[\"0x8888\"]]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +411,34 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_uint_hex_padding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8,
+					RTE_TEL_U8_BITS);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88,
+					RTE_TEL_U16_BITS);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888,
+					RTE_TEL_U32_BITS);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888,
+					RTE_TEL_U64_BITS);
+
+	return CHECK_OUTPUT("[\"0x08\",\"0x0088\",\"0x00000888\",\"0x0000000000008888\"]");
+}
+
+static int
+test_case_array_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("[\"0x8\",\"0x88\",\"0x888\",\"0x8888\"]");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -429,15 +579,23 @@ telemetry_data_autotest(void)
 			test_simple_string,
 			test_case_array_string,
 			test_case_array_int, test_case_array_u64,
+			test_case_array_uint_hex_padding,
+			test_case_array_uint_hex_nopadding,
 			test_case_add_dict_int, test_case_add_dict_u64,
 			test_case_add_dict_string,
+			test_case_add_dict_uint_hex_padding,
+			test_case_add_dict_uint_hex_nopadding,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_dict_with_array_uint_hex_values_padding,
+			test_dict_with_array_uint_hex_values_nopadding,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_array_with_array_uint_hex_values_padding,
+			test_array_with_array_uint_hex_values_nopadding,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V4 9/9] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index a40d396677..3e3b7febaa 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,13 +6068,14 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
-			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
-			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
-			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	rte_tel_data_add_dict_uint_hex(d, "dev_flags",
+			eth_dev->data->dev_flags, 0);
+	rte_tel_data_add_dict_uint_hex(d, "rx_offloads",
+			eth_dev->data->dev_conf.rxmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "tx_offloads",
+			eth_dev->data->dev_conf.txmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "ethdev_rss_hf",
+			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf, 0);
 
 	return 0;
 }
-- 
2.33.0

RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Morten Brørup]

Med venlig hilsen / Kind regards,
-Morten Brørup


> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 13.16
> To: Morten Brørup
> Cc: Huisong Li; dev@dpdk.org; ciara.power@intel.com;
> liudongdong3@huawei.com; huangdaode@huawei.com; fengchengwen@huawei.com
> Subject: Re: [PATCH V3 00/11] telemetry: add u32 value type and hex
> integer string API
> 
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > >
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by
> the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer
> capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem
> of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32
> and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix
> ABI
> > > > > break
> > > > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for
> u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space
> internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for
> output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning
> that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a
> u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format,
> but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to
> wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require
> the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To
> make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > >
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would
> make
> > > sense to explicitly add it, but it seems like a lot of extra code
> for
> > > little or no benefit until we support something like that.
> >
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion,
> so the existing _int function should be updated to take an int64_t
> value, and the _u64 function should be renamed to _uint (and still take
> an uint64_t value). However, that would break the ABI, and would need
> to go through some process for that. So let's not change this now.
> > </rant>
> 
> Yes, not making "int" an "i64" type was a poor design decision on my
> part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this
> as
> you suggest at the next ABI break window.
> 
> >
> > I tend to agree with Bruce on this: Let's get rid of the new u32
> functions, and rely on the u64 functions for that instead.
> >
> > >
> > > > >
> > > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > > instead
> > > > > only
> > > > > add the functions for outputting hex values. Those hex output
> > > functions
> > > > > could take an additional parameter indicating the desired hex
> > > output
> > > > > length, as there could well be cases where we want just 16-bit
> hex
> > > > > value
> > > > > too.
> > > >
> > > > The way I read the patch series, the hex output length is not
> fixed,
> > > but an u64 value of 5 will be output as 0x5, not
> 0x0000000000000005.
> > > >
> > > > So the only benefit of having both u32_hex and u64_hex functions
> is
> > > to avoid type promotion from uint32_t to uint64_t on input for 32
> bit
> > > values.
> > > >
> > > > Instead of passing a 3rd parameter or adding u16_hex functions,
> we
> > > could consider just having one set of hex functions using uint64_t
> for
> > > the value, and rely on type promotion for 32 and 16 bit values.
> > > >
> > >
> > > +1 to having only a single hex function, and I think type promotion
> > > should
> > > work fine.
> > >
> > > However, I still think it might be worthwhile allowing the user to
> pass
> > > in
> > > a min output length parameter too. I find for many hex strings
> having
> > > the
> > > leading zeros to explicitly show the length can be useful. The
> value
> > > "0"
> > > could cover the current behaviour of no-padding, otherwise the
> > > parameter
> > > should indicate the number of bits to be displayed. (If we want to
> lock
> > > it
> > > down we can use an enum parameter rather than int to limit it to 0,
> 8,
> > > 16,
> > > 32 or 64 bit displayed values).
> >
> > An extra parameter for minimum output length (in number of input
> bits) would be very nice, and makes avoids a set of functions for each
> bit width.
> >
> > (I don't think it should be lock it down to some special bit lengths;
> there is no need to prevent 24 bit or other exotic bit widths.)
> >
> > Something like this:
> >
> > char str[64]; // Big enough length.
> > if (bits != 0) {
> >   char format[16]; // Big enough length.
> >   sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> >   sprintf(str, format, value);
> > } else {
> >   sprintf(str, "0x%" PRIx64, value);
> > }
> >
> 
> LGTM.

From a higher level perspective, I'm wondering why passing an uint32_t as x to rte_tel_data_add_{dict|array}_int(struct rte_tel_data *d, int x) doesn't produce a compiler warning about risky type conversion. And similarly passing a signed value to the _u64 functions.

Wouldn't it make sense to wrap these functions in a macro, so -Wconversion could be enabled when they are used? (I guess -Wconversion is default disabled when building DPDK.)

-Morten

Re: [PATCH V4 6/9] telemetry: refactor mapping between value and array type

[Bruce Richardson]

On Tue, Dec 13, 2022 at 06:15:09PM +0800, Huisong Li wrote:
> Currently, use rte_tel_value_type as index of array to find the
> tel_container_types in rte_tel_data_start_array. It's not good
> for maintenance.
> 
> Fixes: ed1bfad7d384 ("telemetry: add functions for returning callback data")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++++++------
>  1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> index 34366ecee3..080d99aec9 100644
> --- a/lib/telemetry/telemetry_data.c
> +++ b/lib/telemetry/telemetry_data.c
> @@ -15,13 +15,29 @@
>  int
>  rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
>  {
> -	enum tel_container_types array_types[] = {
> -			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
> -			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
> -			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 2 */
> -			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
> +	struct {
> +		enum rte_tel_value_type value_type;
> +		enum tel_container_types array_type;
> +	} value2array_types_map[] = {
> +		{RTE_TEL_STRING_VAL, RTE_TEL_ARRAY_STRING},
> +		{RTE_TEL_INT_VAL,    RTE_TEL_ARRAY_INT},
> +		{RTE_TEL_U64_VAL,    RTE_TEL_ARRAY_U64},
> +		{RTE_TEL_CONTAINER,  RTE_TEL_ARRAY_CONTAINER},
>  	};
> -	d->type = array_types[type];
> +	int array_types = -1;
> +	uint16_t i;
> +
> +	for (i = 0; i < RTE_DIM(value2array_types_map); i++) {
> +		if (type == value2array_types_map[i].value_type) {
> +			array_types = value2array_types_map[i].array_type;
> +			break;
> +		}
> +	}
> +
While this may need cleanup, I don't think this particular way is the
best method to use, so NAK for this patch for now.

/Bruce

Re: [PATCH V4 7/9] telemetry: support adding integer value as hexadecimal

[Bruce Richardson]

On Tue, Dec 13, 2022 at 06:15:10PM +0800, Huisong Li wrote:
> Sometimes displaying a unsigned integer value as hexadecimal encoded style
> is more expected for human consumption, such as, offload capability and
> device flag. This patch introduces two APIs to add unsigned integer (can be
> one of uint8_t, uint16_t, uint32_t and uint64_t type) value as hexadecimal
> encoded string to array or dictionary. If the 'val_bits' is zero, the value
> is stored as hexadecimal encoded string without padding zero.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>

Thanks for the patch. Agree with the principle of it, but some comments
inline.

/Bruce

> ---
>  lib/telemetry/rte_telemetry.h  | 50 +++++++++++++++++++++++++++++
>  lib/telemetry/telemetry_data.c | 58 ++++++++++++++++++++++++++++++++++
>  lib/telemetry/version.map      |  9 ++++++
>  3 files changed, 117 insertions(+)
> 
> diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
> index 40e9a3bf9d..88b34097b0 100644
> --- a/lib/telemetry/rte_telemetry.h
> +++ b/lib/telemetry/rte_telemetry.h
> @@ -10,6 +10,7 @@ extern "C" {
>  #endif
>  
>  #include <stdint.h>
> +#include <rte_compat.h>
>  
>  /** Maximum length for string used in object. */
>  #define RTE_TEL_MAX_STRING_LEN 128
> @@ -20,6 +21,11 @@ extern "C" {
>  /** Maximum number of array entries. */
>  #define RTE_TEL_MAX_ARRAY_ENTRIES 512
>  
> +#define RTE_TEL_U8_BITS  8
> +#define RTE_TEL_U16_BITS 16
> +#define RTE_TEL_U32_BITS 32
> +#define RTE_TEL_U64_BITS 64
> +

Not sure these are really necessary, but fairly harmless I suppose.

>  /**
>   * @file
>   *
> @@ -153,6 +159,27 @@ int
>  rte_tel_data_add_array_container(struct rte_tel_data *d,
>  		struct rte_tel_data *val, int keep);
>  
> +/**
> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
> + * to an array.
> + * The array must have been started by rte_tel_data_start_array() with
> + * RTE_TEL_STRING_VAL as the type parameter.
> + *
> + * @param d
> + *   The data structure passed to the callback
> + * @param val
> + *   The number to be returned in the array as a hexadecimal encoded strings.
> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t and uint64_t.

Not sure this last line needs to be stated.

> + * @param val_bits
> + *   The total bits of the input 'val'. If val_bits is zero, the value is stored
> + *   in the array as hexadecimal encoded string without padding zero.
> + * @return
> + *   0 on success, negative errno on error
> + */
> +__rte_experimental
> +int rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
> +				    uint16_t val_bits);
> +
Just watch for whitespace consistency and coding standards. The "int"
should be on  a line by itself, so the function name always starts in
column 0 of a line.

I would also suggest renaming "val_bits" - maybe "display_bitwidth" would
be clearer, though also rather long.

>  /**
>   * Add a string value to a dictionary.
>   * The dict must have been started by rte_tel_data_start_dict().
> @@ -231,6 +258,29 @@ int
>  rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
>  		struct rte_tel_data *val, int keep);
>  
> +/**
> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
> + * to an dictionary.
> + * The dict must have been started by rte_tel_data_start_dict().
> + *
> + * @param d
> + *   The data structure passed to the callback
> + * @param name
> + *   The name of the value is to be stored in the dict
> + *   Must contain only alphanumeric characters or the symbols: '_' or '/'
> + * @param val
> + *   The number to be stored in the dict as a hexadecimal encoded strings.
> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t and uint64_t.
> + * @param val_bits
> + *   The total bits of the input 'val'. If val_bits is zero, the value is stored
> + *   in the array as hexadecimal encoded string without padding zero.
> + * @return
> + *   0 on success, negative errno on error
> + */
> +__rte_experimental
> +int rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
> +				   uint64_t val, uint16_t val_bits);
> +

same comments as above.

>  /**
>   * This telemetry callback is used when registering a telemetry command.
>   * It handles getting and formatting information to be returned to telemetry
> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> index 080d99aec9..fb2f711d99 100644
> --- a/lib/telemetry/telemetry_data.c
> +++ b/lib/telemetry/telemetry_data.c
> @@ -4,6 +4,7 @@
>  
>  #include <errno.h>
>  #include <stdlib.h>
> +#include <inttypes.h>
>  
>  #undef RTE_USE_LIBBSD
>  #include <stdbool.h>
> @@ -12,6 +13,9 @@
>  
>  #include "telemetry_data.h"
>  
> +#define RTE_TEL_UINT_HEX_STRING_BUFFER_LEN 64
> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> +
>  int
>  rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
>  {
> @@ -113,6 +117,33 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
>  	return 0;
>  }
>  
> +int
> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
> +				uint16_t val_bits)
> +{
> +	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
> +
> +	switch (val_bits) {
> +	case RTE_TEL_U8_BITS:
> +		sprintf(hex_str, "0x%02"PRIx64"", val);
> +		break;
> +	case RTE_TEL_U16_BITS:
> +		sprintf(hex_str, "0x%04"PRIx64"", val);
> +		break;
> +	case RTE_TEL_U32_BITS:
> +		sprintf(hex_str, "0x%08"PRIx64"", val);
> +		break;
> +	case RTE_TEL_U64_BITS:
> +		sprintf(hex_str, "0x%016"PRIx64"", val);
> +		break;
> +	default:
> +		sprintf(hex_str, "0x%"PRIx64"", val);
> +		break;
> +	}
> +
> +	return rte_tel_data_add_array_string(d, hex_str);
> +}
> +

This assume we only want those power-of-2 sizes. Is there a reason why we
can't use the code suggested by Morten in the discussion on v3? Having the
extra flexibility might be nice if we can get it.

If we do need to limit to only 8/16/32/64, then I recommend using an enum
in the header rather than #defines for those values. That makes it clearer
that only a very limited range is supported.

Also, code above treats all values other than 8/16/32/64 as if they were 0.
If 20, for example, is passed, we probably want to return error rather than
treating it as zero.

>  static bool
>  valid_name(const char *name)
>  {
> @@ -220,6 +251,33 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
>  	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
>  }
>  
> +int
> +rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
> +			       uint64_t val, uint16_t val_bits)
> +{
> +	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
> +
> +	switch (val_bits) {
> +	case RTE_TEL_U8_BITS:
> +		sprintf(hex_str, "0x%02"PRIx64"", val);
> +		break;
> +	case RTE_TEL_U16_BITS:
> +		sprintf(hex_str, "0x%04"PRIx64"", val);
> +		break;
> +	case RTE_TEL_U32_BITS:
> +		sprintf(hex_str, "0x%08"PRIx64"", val);
> +		break;
> +	case RTE_TEL_U64_BITS:
> +		sprintf(hex_str, "0x%016"PRIx64"", val);
> +		break;
> +	default:
> +		sprintf(hex_str, "0x%"PRIx64"", val);
> +		break;
> +	}
> +

I think the code for converting to hex should be in a common function used
by both the array and dict add functions, rather than duplicated as here.

> +	return rte_tel_data_add_dict_string(d, name, hex_str);
> +}
> +
>  struct rte_tel_data *
>  rte_tel_data_alloc(void)
>  {
> diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
> index 9794f9ea20..951bd63974 100644
> --- a/lib/telemetry/version.map
> +++ b/lib/telemetry/version.map
> @@ -1,3 +1,12 @@
> +EXPERIMENTAL {
> +	global:
> +
> +	rte_tel_data_add_array_uint_hex;
> +	rte_tel_data_add_dict_uint_hex;
> +
> +	local: *;
> +};
> +
>  DPDK_23 {
>  	global:
>  
> -- 
> 2.33.0
> 

Re: [PATCH V4 1/9] telemetry: move to header to controllable range

[Bruce Richardson]

On Tue, Dec 13, 2022 at 06:15:04PM +0800, Huisong Li wrote:
> The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
> this header is uncontrollable. So this patch moves this header to inside
> '_RTE_TELEMETRY_H_'.

s/uncontrollable/unconditional/ ??

> 
> Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API

[Bruce Richardson]

On Mon, Dec 12, 2022 at 12:16:07PM +0000, Bruce Richardson wrote:
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > > 
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32 and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log.  -v2: - fix ABI
> > > > > break
> > > > > > warning.  - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format, but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > > 
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would make
> > > sense to explicitly add it, but it seems like a lot of extra code for
> > > little or no benefit until we support something like that.
> > 
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> > </rant>
> 
> Yes, not making "int" an "i64" type was a poor design decision on my part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this as
> you suggest at the next ABI break window.
> 
Actually, most of the work for this can be done without affecting ABI, I
believe, and for the two functions that would be affected, function
versioning could be used to cover those. I think it's better to make the
change now using versioning rather than waiting, as it's likely to be
forgotten if we wait.

I'll work up a patchset for this so we can review and discuss...

/Bruce

Re: [PATCH V4 7/9] telemetry: support adding integer value as hexadecimal

[lihuisong (C)]

在 2022/12/14 1:09, Bruce Richardson 写道:
> On Tue, Dec 13, 2022 at 06:15:10PM +0800, Huisong Li wrote:
>> Sometimes displaying a unsigned integer value as hexadecimal encoded style
>> is more expected for human consumption, such as, offload capability and
>> device flag. This patch introduces two APIs to add unsigned integer (can be
>> one of uint8_t, uint16_t, uint32_t and uint64_t type) value as hexadecimal
>> encoded string to array or dictionary. If the 'val_bits' is zero, the value
>> is stored as hexadecimal encoded string without padding zero.
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> Thanks for the patch. Agree with the principle of it, but some comments
> inline.
>
> /Bruce
>
>> ---
>>   lib/telemetry/rte_telemetry.h  | 50 +++++++++++++++++++++++++++++
>>   lib/telemetry/telemetry_data.c | 58 ++++++++++++++++++++++++++++++++++
>>   lib/telemetry/version.map      |  9 ++++++
>>   3 files changed, 117 insertions(+)
>>
>> diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
>> index 40e9a3bf9d..88b34097b0 100644
>> --- a/lib/telemetry/rte_telemetry.h
>> +++ b/lib/telemetry/rte_telemetry.h
>> @@ -10,6 +10,7 @@ extern "C" {
>>   #endif
>>   
>>   #include <stdint.h>
>> +#include <rte_compat.h>
>>   
>>   /** Maximum length for string used in object. */
>>   #define RTE_TEL_MAX_STRING_LEN 128
>> @@ -20,6 +21,11 @@ extern "C" {
>>   /** Maximum number of array entries. */
>>   #define RTE_TEL_MAX_ARRAY_ENTRIES 512
>>   
>> +#define RTE_TEL_U8_BITS  8
>> +#define RTE_TEL_U16_BITS 16
>> +#define RTE_TEL_U32_BITS 32
>> +#define RTE_TEL_U64_BITS 64
>> +
> Not sure these are really necessary, but fairly harmless I suppose.
This is convenient for the user to use.
>
>>   /**
>>    * @file
>>    *
>> @@ -153,6 +159,27 @@ int
>>   rte_tel_data_add_array_container(struct rte_tel_data *d,
>>   		struct rte_tel_data *val, int keep);
>>   
>> +/**
>> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
>> + * to an array.
>> + * The array must have been started by rte_tel_data_start_array() with
>> + * RTE_TEL_STRING_VAL as the type parameter.
>> + *
>> + * @param d
>> + *   The data structure passed to the callback
>> + * @param val
>> + *   The number to be returned in the array as a hexadecimal encoded strings.
>> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t and uint64_t.
> Not sure this last line needs to be stated.
>
>> + * @param val_bits
>> + *   The total bits of the input 'val'. If val_bits is zero, the value is stored
>> + *   in the array as hexadecimal encoded string without padding zero.
>> + * @return
>> + *   0 on success, negative errno on error
>> + */
>> +__rte_experimental
>> +int rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
>> +				    uint16_t val_bits);
>> +
> Just watch for whitespace consistency and coding standards. The "int"
> should be on  a line by itself, so the function name always starts in
> column 0 of a line.
Sorry, I refer to a wrong example.
>
> I would also suggest renaming "val_bits" - maybe "display_bitwidth" would
> be clearer, though also rather long.
The 'val_bits' means the total bits of input 'val', It also reflects the 
type of data
to be stored in hexadecimal. After all, we use 'u64' to cover all 
unisgned integer types.
And this function is introduced for adding hexadecimal format value, not 
binary format.
The value can not be stored exactly according to the input 
"display_bitwidth".
If we limit to only 8/16/32/64 integer types, the 'val_bits' is better, 
I think.
>
>>   /**
>>    * Add a string value to a dictionary.
>>    * The dict must have been started by rte_tel_data_start_dict().
>> @@ -231,6 +258,29 @@ int
>>   rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
>>   		struct rte_tel_data *val, int keep);
>>   
>> +/**
>> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
>> + * to an dictionary.
>> + * The dict must have been started by rte_tel_data_start_dict().
>> + *
>> + * @param d
>> + *   The data structure passed to the callback
>> + * @param name
>> + *   The name of the value is to be stored in the dict
>> + *   Must contain only alphanumeric characters or the symbols: '_' or '/'
>> + * @param val
>> + *   The number to be stored in the dict as a hexadecimal encoded strings.
>> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t and uint64_t.
>> + * @param val_bits
>> + *   The total bits of the input 'val'. If val_bits is zero, the value is stored
>> + *   in the array as hexadecimal encoded string without padding zero.
>> + * @return
>> + *   0 on success, negative errno on error
>> + */
>> +__rte_experimental
>> +int rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
>> +				   uint64_t val, uint16_t val_bits);
>> +
> same comments as above.
>
>>   /**
>>    * This telemetry callback is used when registering a telemetry command.
>>    * It handles getting and formatting information to be returned to telemetry
>> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
>> index 080d99aec9..fb2f711d99 100644
>> --- a/lib/telemetry/telemetry_data.c
>> +++ b/lib/telemetry/telemetry_data.c
>> @@ -4,6 +4,7 @@
>>   
>>   #include <errno.h>
>>   #include <stdlib.h>
>> +#include <inttypes.h>
>>   
>>   #undef RTE_USE_LIBBSD
>>   #include <stdbool.h>
>> @@ -12,6 +13,9 @@
>>   
>>   #include "telemetry_data.h"
>>   
>> +#define RTE_TEL_UINT_HEX_STRING_BUFFER_LEN 64
>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
>> +
>>   int
>>   rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
>>   {
>> @@ -113,6 +117,33 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
>>   	return 0;
>>   }
>>   
>> +int
>> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
>> +				uint16_t val_bits)
>> +{
>> +	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
>> +
>> +	switch (val_bits) {
>> +	case RTE_TEL_U8_BITS:
>> +		sprintf(hex_str, "0x%02"PRIx64"", val);
>> +		break;
>> +	case RTE_TEL_U16_BITS:
>> +		sprintf(hex_str, "0x%04"PRIx64"", val);
>> +		break;
>> +	case RTE_TEL_U32_BITS:
>> +		sprintf(hex_str, "0x%08"PRIx64"", val);
>> +		break;
>> +	case RTE_TEL_U64_BITS:
>> +		sprintf(hex_str, "0x%016"PRIx64"", val);
>> +		break;
>> +	default:
>> +		sprintf(hex_str, "0x%"PRIx64"", val);
>> +		break;
>> +	}
>> +
>> +	return rte_tel_data_add_array_string(d, hex_str);
>> +}
>> +
> This assume we only want those power-of-2 sizes. Is there a reason why we
> can't use the code suggested by Morten in the discussion on v3? Having the
> extra flexibility might be nice if we can get it.
The compiler doesn't like it. There is a warning:
'warning: format not a string literal, argument types not checked 
[-Wformat-nonliteral]'
>
> If we do need to limit to only 8/16/32/64, then I recommend using an enum
> in the header rather than #defines for those values. That makes it clearer
> that only a very limited range is supported.
>
> Also, code above treats all values other than 8/16/32/64 as if they were 0.
> If 20, for example, is passed, we probably want to return error rather than
> treating it as zero.
I have to only consider 8/16/32/64 integer types because of above warning.
In addition, the normal unsigned integer data is one of them. If user forces
'0xf1f23' value to 10 bitwidth to display, it will be truncated as 0xf23.
It seems pointless and unfriendly.
So overall, this function is limited to all uint types, and is currently 
fully adequate.

Do we need to check other bitwidth? If the 'val_bits' isn't 8/16/32/64, 
it is processed as
no-padding zero.
>
>>   static bool
>>   valid_name(const char *name)
>>   {
>> @@ -220,6 +251,33 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
>>   	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
>>   }
>>   
>> +int
>> +rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
>> +			       uint64_t val, uint16_t val_bits)
>> +{
>> +	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
>> +
>> +	switch (val_bits) {
>> +	case RTE_TEL_U8_BITS:
>> +		sprintf(hex_str, "0x%02"PRIx64"", val);
>> +		break;
>> +	case RTE_TEL_U16_BITS:
>> +		sprintf(hex_str, "0x%04"PRIx64"", val);
>> +		break;
>> +	case RTE_TEL_U32_BITS:
>> +		sprintf(hex_str, "0x%08"PRIx64"", val);
>> +		break;
>> +	case RTE_TEL_U64_BITS:
>> +		sprintf(hex_str, "0x%016"PRIx64"", val);
>> +		break;
>> +	default:
>> +		sprintf(hex_str, "0x%"PRIx64"", val);
>> +		break;
>> +	}
>> +
> I think the code for converting to hex should be in a common function used
> by both the array and dict add functions, rather than duplicated as here.
Ack
>
>> +	return rte_tel_data_add_dict_string(d, name, hex_str);
>> +}
>> +
>>   struct rte_tel_data *
>>   rte_tel_data_alloc(void)
>>   {
>> diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
>> index 9794f9ea20..951bd63974 100644
>> --- a/lib/telemetry/version.map
>> +++ b/lib/telemetry/version.map
>> @@ -1,3 +1,12 @@
>> +EXPERIMENTAL {
>> +	global:
>> +
>> +	rte_tel_data_add_array_uint_hex;
>> +	rte_tel_data_add_dict_uint_hex;
>> +
>> +	local: *;
>> +};
>> +
>>   DPDK_23 {
>>   	global:
>>   
>> -- 
>> 2.33.0
>>
> .

Re: [PATCH V4 1/9] telemetry: move to header to controllable range

[lihuisong (C)]

在 2022/12/14 1:10, Bruce Richardson 写道:
> On Tue, Dec 13, 2022 at 06:15:04PM +0800, Huisong Li wrote:
>> The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
>> this header is uncontrollable. So this patch moves this header to inside
>> '_RTE_TELEMETRY_H_'.
> s/uncontrollable/unconditional/ ??
Ack
>
>> Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> .

Re: [PATCH V4 6/9] telemetry: refactor mapping between value and array type

[lihuisong (C)]

在 2022/12/14 0:57, Bruce Richardson 写道:
> On Tue, Dec 13, 2022 at 06:15:09PM +0800, Huisong Li wrote:
>> Currently, use rte_tel_value_type as index of array to find the
>> tel_container_types in rte_tel_data_start_array. It's not good
>> for maintenance.
>>
>> Fixes: ed1bfad7d384 ("telemetry: add functions for returning callback data")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>>   lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++++++------
>>   1 file changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
>> index 34366ecee3..080d99aec9 100644
>> --- a/lib/telemetry/telemetry_data.c
>> +++ b/lib/telemetry/telemetry_data.c
>> @@ -15,13 +15,29 @@
>>   int
>>   rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
>>   {
>> -	enum tel_container_types array_types[] = {
>> -			RTE_TEL_ARRAY_STRING, /* RTE_TEL_STRING_VAL = 0 */
>> -			RTE_TEL_ARRAY_INT,    /* RTE_TEL_INT_VAL = 1 */
>> -			RTE_TEL_ARRAY_U64,    /* RTE_TEL_u64_VAL = 2 */
>> -			RTE_TEL_ARRAY_CONTAINER, /* RTE_TEL_CONTAINER = 3 */
>> +	struct {
>> +		enum rte_tel_value_type value_type;
>> +		enum tel_container_types array_type;
>> +	} value2array_types_map[] = {
>> +		{RTE_TEL_STRING_VAL, RTE_TEL_ARRAY_STRING},
>> +		{RTE_TEL_INT_VAL,    RTE_TEL_ARRAY_INT},
>> +		{RTE_TEL_U64_VAL,    RTE_TEL_ARRAY_U64},
>> +		{RTE_TEL_CONTAINER,  RTE_TEL_ARRAY_CONTAINER},
>>   	};
>> -	d->type = array_types[type];
>> +	int array_types = -1;
>> +	uint16_t i;
>> +
>> +	for (i = 0; i < RTE_DIM(value2array_types_map); i++) {
>> +		if (type == value2array_types_map[i].value_type) {
>> +			array_types = value2array_types_map[i].array_type;
>> +			break;
>> +		}
>> +	}
>> +
> While this may need cleanup, I don't think this particular way is the
> best method to use, so NAK for this patch for now.
Can you have some advice to optimize it, Bruce?
>
> /Bruce
> .

RE: [PATCH V4 7/9] telemetry: support adding integer value as hexadecimal

[Morten Brørup]

> From: lihuisong (C) [mailto:lihuisong@huawei.com]
> Sent: Wednesday, 14 December 2022 03.44
> 
> 在 2022/12/14 1:09, Bruce Richardson 写道:
> > On Tue, Dec 13, 2022 at 06:15:10PM +0800, Huisong Li wrote:
> >> Sometimes displaying a unsigned integer value as hexadecimal encoded
> style
> >> is more expected for human consumption, such as, offload capability
> and
> >> device flag. This patch introduces two APIs to add unsigned integer
> (can be
> >> one of uint8_t, uint16_t, uint32_t and uint64_t type) value as
> hexadecimal
> >> encoded string to array or dictionary. If the 'val_bits' is zero,
> the value
> >> is stored as hexadecimal encoded string without padding zero.
> >>
> >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> > Thanks for the patch. Agree with the principle of it, but some
> comments
> > inline.
> >
> > /Bruce
> >
> >> ---
> >>   lib/telemetry/rte_telemetry.h  | 50 +++++++++++++++++++++++++++++
> >>   lib/telemetry/telemetry_data.c | 58
> ++++++++++++++++++++++++++++++++++
> >>   lib/telemetry/version.map      |  9 ++++++
> >>   3 files changed, 117 insertions(+)
> >>
> >> diff --git a/lib/telemetry/rte_telemetry.h
> b/lib/telemetry/rte_telemetry.h
> >> index 40e9a3bf9d..88b34097b0 100644
> >> --- a/lib/telemetry/rte_telemetry.h
> >> +++ b/lib/telemetry/rte_telemetry.h
> >> @@ -10,6 +10,7 @@ extern "C" {
> >>   #endif
> >>
> >>   #include <stdint.h>
> >> +#include <rte_compat.h>
> >>
> >>   /** Maximum length for string used in object. */
> >>   #define RTE_TEL_MAX_STRING_LEN 128
> >> @@ -20,6 +21,11 @@ extern "C" {
> >>   /** Maximum number of array entries. */
> >>   #define RTE_TEL_MAX_ARRAY_ENTRIES 512
> >>
> >> +#define RTE_TEL_U8_BITS  8
> >> +#define RTE_TEL_U16_BITS 16
> >> +#define RTE_TEL_U32_BITS 32
> >> +#define RTE_TEL_U64_BITS 64
> >> +
> > Not sure these are really necessary, but fairly harmless I suppose.
> This is convenient for the user to use.
> >
> >>   /**
> >>    * @file
> >>    *
> >> @@ -153,6 +159,27 @@ int
> >>   rte_tel_data_add_array_container(struct rte_tel_data *d,
> >>   		struct rte_tel_data *val, int keep);
> >>
> >> +/**
> >> + * Convert a unsigned integer to hexadecimal encoded strings and
> add this string
> >> + * to an array.
> >> + * The array must have been started by rte_tel_data_start_array()
> with
> >> + * RTE_TEL_STRING_VAL as the type parameter.
> >> + *
> >> + * @param d
> >> + *   The data structure passed to the callback
> >> + * @param val
> >> + *   The number to be returned in the array as a hexadecimal
> encoded strings.
> >> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t
> and uint64_t.
> > Not sure this last line needs to be stated.
> >
> >> + * @param val_bits
> >> + *   The total bits of the input 'val'. If val_bits is zero, the
> value is stored
> >> + *   in the array as hexadecimal encoded string without padding
> zero.
> >> + * @return
> >> + *   0 on success, negative errno on error
> >> + */
> >> +__rte_experimental
> >> +int rte_tel_data_add_array_uint_hex(struct rte_tel_data *d,
> uint64_t val,
> >> +				    uint16_t val_bits);
> >> +
> > Just watch for whitespace consistency and coding standards. The "int"
> > should be on  a line by itself, so the function name always starts in
> > column 0 of a line.
> Sorry, I refer to a wrong example.
> >
> > I would also suggest renaming "val_bits" - maybe "display_bitwidth"
> would
> > be clearer, though also rather long.
> The 'val_bits' means the total bits of input 'val', It also reflects
> the
> type of data
> to be stored in hexadecimal. After all, we use 'u64' to cover all
> unisgned integer types.
> And this function is introduced for adding hexadecimal format value,
> not
> binary format.
> The value can not be stored exactly according to the input
> "display_bitwidth".
> If we limit to only 8/16/32/64 integer types, the 'val_bits' is better,
> I think.

NAK to limiting the bitwidth to 8/16/32/64 bits!

The function should be able to dump bitfields, such as the TCP flags, where the bitwidth is 6.

> >
> >>   /**
> >>    * Add a string value to a dictionary.
> >>    * The dict must have been started by rte_tel_data_start_dict().
> >> @@ -231,6 +258,29 @@ int
> >>   rte_tel_data_add_dict_container(struct rte_tel_data *d, const char
> *name,
> >>   		struct rte_tel_data *val, int keep);
> >>
> >> +/**
> >> + * Convert a unsigned integer to hexadecimal encoded strings and
> add this string
> >> + * to an dictionary.
> >> + * The dict must have been started by rte_tel_data_start_dict().
> >> + *
> >> + * @param d
> >> + *   The data structure passed to the callback
> >> + * @param name
> >> + *   The name of the value is to be stored in the dict
> >> + *   Must contain only alphanumeric characters or the symbols: '_'
> or '/'
> >> + * @param val
> >> + *   The number to be stored in the dict as a hexadecimal encoded
> strings.
> >> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t
> and uint64_t.
> >> + * @param val_bits
> >> + *   The total bits of the input 'val'. If val_bits is zero, the
> value is stored
> >> + *   in the array as hexadecimal encoded string without padding
> zero.
> >> + * @return
> >> + *   0 on success, negative errno on error
> >> + */
> >> +__rte_experimental
> >> +int rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const
> char *name,
> >> +				   uint64_t val, uint16_t val_bits);
> >> +
> > same comments as above.
> >
> >>   /**
> >>    * This telemetry callback is used when registering a telemetry
> command.
> >>    * It handles getting and formatting information to be returned to
> telemetry
> >> diff --git a/lib/telemetry/telemetry_data.c
> b/lib/telemetry/telemetry_data.c
> >> index 080d99aec9..fb2f711d99 100644
> >> --- a/lib/telemetry/telemetry_data.c
> >> +++ b/lib/telemetry/telemetry_data.c
> >> @@ -4,6 +4,7 @@
> >>
> >>   #include <errno.h>
> >>   #include <stdlib.h>
> >> +#include <inttypes.h>
> >>
> >>   #undef RTE_USE_LIBBSD
> >>   #include <stdbool.h>
> >> @@ -12,6 +13,9 @@
> >>
> >>   #include "telemetry_data.h"
> >>
> >> +#define RTE_TEL_UINT_HEX_STRING_BUFFER_LEN 64
> >> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> >> +
> >>   int
> >>   rte_tel_data_start_array(struct rte_tel_data *d, enum
> rte_tel_value_type type)
> >>   {
> >> @@ -113,6 +117,33 @@ rte_tel_data_add_array_container(struct
> rte_tel_data *d,
> >>   	return 0;
> >>   }
> >>
> >> +int
> >> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t
> val,
> >> +				uint16_t val_bits)
> >> +{
> >> +	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
> >> +
> >> +	switch (val_bits) {
> >> +	case RTE_TEL_U8_BITS:
> >> +		sprintf(hex_str, "0x%02"PRIx64"", val);
> >> +		break;
> >> +	case RTE_TEL_U16_BITS:
> >> +		sprintf(hex_str, "0x%04"PRIx64"", val);
> >> +		break;
> >> +	case RTE_TEL_U32_BITS:
> >> +		sprintf(hex_str, "0x%08"PRIx64"", val);
> >> +		break;
> >> +	case RTE_TEL_U64_BITS:
> >> +		sprintf(hex_str, "0x%016"PRIx64"", val);
> >> +		break;
> >> +	default:
> >> +		sprintf(hex_str, "0x%"PRIx64"", val);
> >> +		break;
> >> +	}
> >> +
> >> +	return rte_tel_data_add_array_string(d, hex_str);
> >> +}
> >> +
> > This assume we only want those power-of-2 sizes. Is there a reason
> why we
> > can't use the code suggested by Morten in the discussion on v3?
> Having the
> > extra flexibility might be nice if we can get it.
> The compiler doesn't like it. There is a warning:
> 'warning: format not a string literal, argument types not checked
> [-Wformat-nonliteral]'

You can surround the affected functions by some #pragma to temporarily disable that warning.

I assume you noticed the bugs in my code:

char str[64]; // FIXME: Use correct size.
if (bits != 0) {
  char format[16]; // FIXME: Use correct size.
  sprintf(format, "0x%%0%u" PRIx64, (bits + 3) / 4); // bug fixed here
  sprintf(str, format, value);
} else {
  sprintf(str, "0x%" PRIx64, value);
}


> >
> > If we do need to limit to only 8/16/32/64, then I recommend using an
> enum
> > in the header rather than #defines for those values. That makes it
> clearer
> > that only a very limited range is supported.
> >
> > Also, code above treats all values other than 8/16/32/64 as if they
> were 0.
> > If 20, for example, is passed, we probably want to return error
> rather than
> > treating it as zero.
> I have to only consider 8/16/32/64 integer types because of above
> warning.
> In addition, the normal unsigned integer data is one of them. If user
> forces
> '0xf1f23' value to 10 bitwidth to display, it will be truncated as
> 0xf23.

The printf width field specifies the MINIMUM number of characters to output.

Truncation would be a bug in the C library.

> It seems pointless and unfriendly.
> So overall, this function is limited to all uint types, and is
> currently
> fully adequate.
> 
> Do we need to check other bitwidth? If the 'val_bits' isn't 8/16/32/64,
> it is processed as
> no-padding zero.

Re: [PATCH V4 7/9] telemetry: support adding integer value as hexadecimal

[lihuisong (C)]

在 2022/12/14 15:28, Morten Brørup 写道:
>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
>> Sent: Wednesday, 14 December 2022 03.44
>>
>> 在 2022/12/14 1:09, Bruce Richardson 写道:
>>> On Tue, Dec 13, 2022 at 06:15:10PM +0800, Huisong Li wrote:
>>>> Sometimes displaying a unsigned integer value as hexadecimal encoded
>> style
>>>> is more expected for human consumption, such as, offload capability
>> and
>>>> device flag. This patch introduces two APIs to add unsigned integer
>> (can be
>>>> one of uint8_t, uint16_t, uint32_t and uint64_t type) value as
>> hexadecimal
>>>> encoded string to array or dictionary. If the 'val_bits' is zero,
>> the value
>>>> is stored as hexadecimal encoded string without padding zero.
>>>>
>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>>>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>>> Thanks for the patch. Agree with the principle of it, but some
>> comments
>>> inline.
>>>
>>> /Bruce
>>>
>>>> ---
>>>>    lib/telemetry/rte_telemetry.h  | 50 +++++++++++++++++++++++++++++
>>>>    lib/telemetry/telemetry_data.c | 58
>> ++++++++++++++++++++++++++++++++++
>>>>    lib/telemetry/version.map      |  9 ++++++
>>>>    3 files changed, 117 insertions(+)
>>>>
>>>> diff --git a/lib/telemetry/rte_telemetry.h
>> b/lib/telemetry/rte_telemetry.h
>>>> index 40e9a3bf9d..88b34097b0 100644
>>>> --- a/lib/telemetry/rte_telemetry.h
>>>> +++ b/lib/telemetry/rte_telemetry.h
>>>> @@ -10,6 +10,7 @@ extern "C" {
>>>>    #endif
>>>>
>>>>    #include <stdint.h>
>>>> +#include <rte_compat.h>
>>>>
>>>>    /** Maximum length for string used in object. */
>>>>    #define RTE_TEL_MAX_STRING_LEN 128
>>>> @@ -20,6 +21,11 @@ extern "C" {
>>>>    /** Maximum number of array entries. */
>>>>    #define RTE_TEL_MAX_ARRAY_ENTRIES 512
>>>>
>>>> +#define RTE_TEL_U8_BITS  8
>>>> +#define RTE_TEL_U16_BITS 16
>>>> +#define RTE_TEL_U32_BITS 32
>>>> +#define RTE_TEL_U64_BITS 64
>>>> +
>>> Not sure these are really necessary, but fairly harmless I suppose.
>> This is convenient for the user to use.
>>>>    /**
>>>>     * @file
>>>>     *
>>>> @@ -153,6 +159,27 @@ int
>>>>    rte_tel_data_add_array_container(struct rte_tel_data *d,
>>>>    		struct rte_tel_data *val, int keep);
>>>>
>>>> +/**
>>>> + * Convert a unsigned integer to hexadecimal encoded strings and
>> add this string
>>>> + * to an array.
>>>> + * The array must have been started by rte_tel_data_start_array()
>> with
>>>> + * RTE_TEL_STRING_VAL as the type parameter.
>>>> + *
>>>> + * @param d
>>>> + *   The data structure passed to the callback
>>>> + * @param val
>>>> + *   The number to be returned in the array as a hexadecimal
>> encoded strings.
>>>> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t
>> and uint64_t.
>>> Not sure this last line needs to be stated.
>>>
>>>> + * @param val_bits
>>>> + *   The total bits of the input 'val'. If val_bits is zero, the
>> value is stored
>>>> + *   in the array as hexadecimal encoded string without padding
>> zero.
>>>> + * @return
>>>> + *   0 on success, negative errno on error
>>>> + */
>>>> +__rte_experimental
>>>> +int rte_tel_data_add_array_uint_hex(struct rte_tel_data *d,
>> uint64_t val,
>>>> +				    uint16_t val_bits);
>>>> +
>>> Just watch for whitespace consistency and coding standards. The "int"
>>> should be on  a line by itself, so the function name always starts in
>>> column 0 of a line.
>> Sorry, I refer to a wrong example.
>>> I would also suggest renaming "val_bits" - maybe "display_bitwidth"
>> would
>>> be clearer, though also rather long.
>> The 'val_bits' means the total bits of input 'val', It also reflects
>> the
>> type of data
>> to be stored in hexadecimal. After all, we use 'u64' to cover all
>> unisgned integer types.
>> And this function is introduced for adding hexadecimal format value,
>> not
>> binary format.
>> The value can not be stored exactly according to the input
>> "display_bitwidth".
>> If we limit to only 8/16/32/64 integer types, the 'val_bits' is better,
>> I think.
> NAK to limiting the bitwidth to 8/16/32/64 bits!
>
> The function should be able to dump bitfields, such as the TCP flags, where the bitwidth is 6.
>
>>>>    /**
>>>>     * Add a string value to a dictionary.
>>>>     * The dict must have been started by rte_tel_data_start_dict().
>>>> @@ -231,6 +258,29 @@ int
>>>>    rte_tel_data_add_dict_container(struct rte_tel_data *d, const char
>> *name,
>>>>    		struct rte_tel_data *val, int keep);
>>>>
>>>> +/**
>>>> + * Convert a unsigned integer to hexadecimal encoded strings and
>> add this string
>>>> + * to an dictionary.
>>>> + * The dict must have been started by rte_tel_data_start_dict().
>>>> + *
>>>> + * @param d
>>>> + *   The data structure passed to the callback
>>>> + * @param name
>>>> + *   The name of the value is to be stored in the dict
>>>> + *   Must contain only alphanumeric characters or the symbols: '_'
>> or '/'
>>>> + * @param val
>>>> + *   The number to be stored in the dict as a hexadecimal encoded
>> strings.
>>>> + *   The type of ''val' can be one of uint8_t, uint16_t, uint32_t
>> and uint64_t.
>>>> + * @param val_bits
>>>> + *   The total bits of the input 'val'. If val_bits is zero, the
>> value is stored
>>>> + *   in the array as hexadecimal encoded string without padding
>> zero.
>>>> + * @return
>>>> + *   0 on success, negative errno on error
>>>> + */
>>>> +__rte_experimental
>>>> +int rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const
>> char *name,
>>>> +				   uint64_t val, uint16_t val_bits);
>>>> +
>>> same comments as above.
>>>
>>>>    /**
>>>>     * This telemetry callback is used when registering a telemetry
>> command.
>>>>     * It handles getting and formatting information to be returned to
>> telemetry
>>>> diff --git a/lib/telemetry/telemetry_data.c
>> b/lib/telemetry/telemetry_data.c
>>>> index 080d99aec9..fb2f711d99 100644
>>>> --- a/lib/telemetry/telemetry_data.c
>>>> +++ b/lib/telemetry/telemetry_data.c
>>>> @@ -4,6 +4,7 @@
>>>>
>>>>    #include <errno.h>
>>>>    #include <stdlib.h>
>>>> +#include <inttypes.h>
>>>>
>>>>    #undef RTE_USE_LIBBSD
>>>>    #include <stdbool.h>
>>>> @@ -12,6 +13,9 @@
>>>>
>>>>    #include "telemetry_data.h"
>>>>
>>>> +#define RTE_TEL_UINT_HEX_STRING_BUFFER_LEN 64
>>>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
>>>> +
>>>>    int
>>>>    rte_tel_data_start_array(struct rte_tel_data *d, enum
>> rte_tel_value_type type)
>>>>    {
>>>> @@ -113,6 +117,33 @@ rte_tel_data_add_array_container(struct
>> rte_tel_data *d,
>>>>    	return 0;
>>>>    }
>>>>
>>>> +int
>>>> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t
>> val,
>>>> +				uint16_t val_bits)
>>>> +{
>>>> +	char hex_str[RTE_TEL_UINT_HEX_STRING_BUFFER_LEN];
>>>> +
>>>> +	switch (val_bits) {
>>>> +	case RTE_TEL_U8_BITS:
>>>> +		sprintf(hex_str, "0x%02"PRIx64"", val);
>>>> +		break;
>>>> +	case RTE_TEL_U16_BITS:
>>>> +		sprintf(hex_str, "0x%04"PRIx64"", val);
>>>> +		break;
>>>> +	case RTE_TEL_U32_BITS:
>>>> +		sprintf(hex_str, "0x%08"PRIx64"", val);
>>>> +		break;
>>>> +	case RTE_TEL_U64_BITS:
>>>> +		sprintf(hex_str, "0x%016"PRIx64"", val);
>>>> +		break;
>>>> +	default:
>>>> +		sprintf(hex_str, "0x%"PRIx64"", val);
>>>> +		break;
>>>> +	}
>>>> +
>>>> +	return rte_tel_data_add_array_string(d, hex_str);
>>>> +}
>>>> +
>>> This assume we only want those power-of-2 sizes. Is there a reason
>> why we
>>> can't use the code suggested by Morten in the discussion on v3?
>> Having the
>>> extra flexibility might be nice if we can get it.
>> The compiler doesn't like it. There is a warning:
>> 'warning: format not a string literal, argument types not checked
>> [-Wformat-nonliteral]'
> You can surround the affected functions by some #pragma to temporarily disable that warning.
Good idea! I will fix it in V5.
>
> I assume you noticed the bugs in my code:
>
> char str[64]; // FIXME: Use correct size.
> if (bits != 0) {
>    char format[16]; // FIXME: Use correct size.
>    sprintf(format, "0x%%0%u" PRIx64, (bits + 3) / 4); // bug fixed here
>    sprintf(str, format, value);
> } else {
>    sprintf(str, "0x%" PRIx64, value);
> }
>
>
>>> If we do need to limit to only 8/16/32/64, then I recommend using an
>> enum
>>> in the header rather than #defines for those values. That makes it
>> clearer
>>> that only a very limited range is supported.
>>>
>>> Also, code above treats all values other than 8/16/32/64 as if they
>> were 0.
>>> If 20, for example, is passed, we probably want to return error
>> rather than
>>> treating it as zero.
>> I have to only consider 8/16/32/64 integer types because of above
>> warning.
>> In addition, the normal unsigned integer data is one of them. If user
>> forces
>> '0xf1f23' value to 10 bitwidth to display, it will be truncated as
>> 0xf23.
> The printf width field specifies the MINIMUM number of characters to output.
>
> Truncation would be a bug in the C library.
>
>> It seems pointless and unfriendly.
>> So overall, this function is limited to all uint types, and is
>> currently
>> fully adequate.
>>
>> Do we need to check other bitwidth? If the 'val_bits' isn't 8/16/32/64,
>> it is processed as
>> no-padding zero.
>

[PATCH V5 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  74 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 310 insertions(+), 30 deletions(-)

-- 
2.33.0

[PATCH V5 1/8] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is unconditional. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V5 2/8] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..a40d396677 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V5 3/8] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..950d01ffac 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u64(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u64(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u64(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u64(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u64(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u64(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u64(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u64(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u64(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V5 4/8] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data
needs to use the 'u64' APIs to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..515d0df5ce 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u64(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V5 5/8] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..8e427bf4b4 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V5 6/8] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a unsigned integer value as hexadecimal encoded style
is more expected for human consumption, such as, offload capability and
device flag. This patch introduces two APIs to add unsigned integer value
as hexadecimal encoded string to array or dictionary. And user can choose
whether the stored value is padding to the specified width.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 47 +++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 74 ++++++++++++++++++++++++++++++++++
 lib/telemetry/version.map      |  9 +++++
 3 files changed, 130 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..b24f0310ea 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -153,6 +154,28 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param val
+ *   The number to be returned in the array as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -231,6 +254,30 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name of the value is to be stored in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..14cb56d680 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,8 @@
 
 #include "telemetry_data.h"
 
+#define RTE_TEL_UINT_HEX_STR_BUF_LEN 64
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -97,6 +100,60 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+/* To suppress compiler warning about format string. */
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wformat-nonliteral"
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wformat-nonliteral"
+#endif
+
+static int
+rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t val,
+				uint8_t display_bitwidth)
+{
+#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
+
+	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
+	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
+
+	/* Buffer needs to have room to contain the prefix '0x' and '\0'. */
+	if (len < spec_hex_width + 3)
+		return -EINVAL;
+
+	if (display_bitwidth != 0) {
+		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
+		sprintf(buf, format, val);
+	} else {
+		sprintf(buf, "0x%" PRIx64, val);
+	}
+
+	return 0;
+}
+
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic pop
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic pop
+#endif
+
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+					      RTE_TEL_UINT_HEX_STR_BUF_LEN, val,
+					      display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -204,6 +261,23 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+					      RTE_TEL_UINT_HEX_STR_BUF_LEN, val,
+					      display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..951bd63974 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_uint_hex;
+	rte_tel_data_add_dict_uint_hex;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V5 7/8] test: add test cases for adding hex integer value API

[Huisong Li]

Add test cases for adding hexadecimal unsigned integer value API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..e930457f4d 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -209,6 +209,39 @@ test_case_add_dict_string(void)
 	return CHECK_OUTPUT("{\"dict_0\":\"aaaa\",\"dict_1\":\"bbbb\",\"dict_2\":\"cccc\",\"dict_3\":\"dddd\"}");
 }
 
+static int
+test_case_add_dict_uint_hex_padding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 8);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 16);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 32);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x08\",\"dict_1\":\"0x0088\",\"dict_2\":\"0x00000888\",\"dict_3\":\"0x0000000000008888\"}");
+}
+
+static int
+test_case_add_dict_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x8\",\"dict_1\":\"0x88\",\"dict_2\":\"0x888\",\"dict_3\":\"0x8888\"}");
+}
 
 static int
 test_dict_with_array_string_values(void)
@@ -232,6 +265,50 @@ test_dict_with_array_string_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[\"aaaa\"],\"dict_1\":[\"bbbb\"]}");
 }
 
+static int
+test_dict_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x00000888\"],\"dict_1\":[\"0x0000000000008888\"]}");
+}
+
+static int
+test_dict_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x888\"],\"dict_1\":[\"0x8888\"]}");
+}
+
 static int
 test_dict_with_dict_values(void)
 {
@@ -278,6 +355,47 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_array_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x00000888\"],[\"0x0000000000008888\"]]");
+}
+
+
+static int
+test_array_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x888\"],[\"0x8888\"]]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +407,30 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_uint_hex_padding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 8);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 16);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("[\"0x08\",\"0x0088\",\"0x00000888\",\"0x0000000000008888\"]");
+}
+
+static int
+test_case_array_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("[\"0x8\",\"0x88\",\"0x888\",\"0x8888\"]");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -429,15 +571,23 @@ telemetry_data_autotest(void)
 			test_simple_string,
 			test_case_array_string,
 			test_case_array_int, test_case_array_u64,
+			test_case_array_uint_hex_padding,
+			test_case_array_uint_hex_nopadding,
 			test_case_add_dict_int, test_case_add_dict_u64,
 			test_case_add_dict_string,
+			test_case_add_dict_uint_hex_padding,
+			test_case_add_dict_uint_hex_nopadding,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_dict_with_array_uint_hex_values_padding,
+			test_dict_with_array_uint_hex_values_nopadding,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_array_with_array_uint_hex_values_padding,
+			test_array_with_array_uint_hex_values_nopadding,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V5 8/8] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index a40d396677..3e3b7febaa 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,13 +6068,14 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
-			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
-			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
-			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	rte_tel_data_add_dict_uint_hex(d, "dev_flags",
+			eth_dev->data->dev_flags, 0);
+	rte_tel_data_add_dict_uint_hex(d, "rx_offloads",
+			eth_dev->data->dev_conf.rxmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "tx_offloads",
+			eth_dev->data->dev_conf.txmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "ethdev_rss_hf",
+			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf, 0);
 
 	return 0;
 }
-- 
2.33.0

RE: [PATCH V5 5/8] mem: possible data truncation and conversion error

[Morten Brørup]

> From: Huisong Li [mailto:lihuisong@huawei.com]
> Sent: Wednesday, 14 December 2022 13.33
> 
> The 'u32' and 'u64' data can not assigned to 'int' type variable.
> They need to use the 'u64' APIs to add.
> 
> Fixes: e6732d0d6e26 ("mem: add telemetry infos")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  lib/eal/common/eal_common_memory.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/eal/common/eal_common_memory.c
> b/lib/eal/common/eal_common_memory.c
> index 688dc615d7..8e427bf4b4 100644
> --- a/lib/eal/common/eal_common_memory.c
> +++ b/lib/eal/common/eal_common_memory.c
> @@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd
> __rte_unused, const char *params,
>  	malloc_heap_get_stats(heap, &sock_stats);
> 
>  	rte_tel_data_start_dict(d);
> -	rte_tel_data_add_dict_int(d, "Head id", heap_id);
> +	rte_tel_data_add_dict_u64(d, "Head id", heap_id);

Consider: "Head id" -> "Heap_id"


>  	rte_tel_data_add_dict_string(d, "Name", heap->name);
>  	rte_tel_data_add_dict_u64(d, "Heap_size",
>  				  sock_stats.heap_totalsz_bytes);
> @@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd
> __rte_unused,
>  	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
> 
>  	rte_tel_data_start_dict(d);
> -	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
> +	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
>  	rte_tel_data_add_dict_string(d, "Name", mz->name);
> -	rte_tel_data_add_dict_int(d, "Length", mz->len);
> +	rte_tel_data_add_dict_u64(d, "Length", mz->len);
>  	snprintf(addr, ADDR_STR, "%p", mz->addr);
>  	rte_tel_data_add_dict_string(d, "Address", addr);
>  	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
> -	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
> +	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
> 
>  	/* go through each page occupied by this memzone */
>  	msl = rte_mem_virt2memseg_list(mz->addr);
> @@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd
> __rte_unused,
>  	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
>  	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
> 
> -	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
> +	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
>  	snprintf(addr, ADDR_STR, "%p", ms->addr);
>  	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
> 
> --
> 2.33.0
> 

Re: [PATCH V5 6/8] telemetry: support adding integer value as hexadecimal

[Bruce Richardson]

On Wed, Dec 14, 2022 at 08:32:51PM +0800, Huisong Li wrote:
> Sometimes displaying a unsigned integer value as hexadecimal encoded style
> is more expected for human consumption, such as, offload capability and
> device flag. This patch introduces two APIs to add unsigned integer value
> as hexadecimal encoded string to array or dictionary. And user can choose
> whether the stored value is padding to the specified width.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  lib/telemetry/rte_telemetry.h  | 47 +++++++++++++++++++++
>  lib/telemetry/telemetry_data.c | 74 ++++++++++++++++++++++++++++++++++
>  lib/telemetry/version.map      |  9 +++++
>  3 files changed, 130 insertions(+)
> 
> diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
> index 40e9a3bf9d..b24f0310ea 100644
> --- a/lib/telemetry/rte_telemetry.h
> +++ b/lib/telemetry/rte_telemetry.h
> @@ -10,6 +10,7 @@ extern "C" {
>  #endif
>  
>  #include <stdint.h>
> +#include <rte_compat.h>
>  
>  /** Maximum length for string used in object. */
>  #define RTE_TEL_MAX_STRING_LEN 128
> @@ -153,6 +154,28 @@ int
>  rte_tel_data_add_array_container(struct rte_tel_data *d,
>  		struct rte_tel_data *val, int keep);
>  
> +/**
> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
> + * to an array.
> + * The array must have been started by rte_tel_data_start_array() with
> + * RTE_TEL_STRING_VAL as the type parameter.
> + *
> + * @param d
> + *   The data structure passed to the callback
> + * @param val
> + *   The number to be returned in the array as a hexadecimal encoded strings.
> + * @param display_bitwidth
> + *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
> + *   value is stored in the array as no-padding zero hexadecimal encoded string,
> + *   or the value is stored as padding zero to specified hexadecimal width.
> + * @return
> + *   0 on success, negative errno on error
> + */
> +__rte_experimental
> +int
> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
> +				uint8_t display_bitwidth);
> +
>  /**
>   * Add a string value to a dictionary.
>   * The dict must have been started by rte_tel_data_start_dict().
> @@ -231,6 +254,30 @@ int
>  rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
>  		struct rte_tel_data *val, int keep);
>  
> +/**
> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
> + * to an dictionary.
> + * The dict must have been started by rte_tel_data_start_dict().
> + *
> + * @param d
> + *   The data structure passed to the callback
> + * @param name
> + *   The name of the value is to be stored in the dict
> + *   Must contain only alphanumeric characters or the symbols: '_' or '/'
> + * @param val
> + *   The number to be stored in the dict as a hexadecimal encoded strings.
> + * @param display_bitwidth
> + *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
> + *   value is stored in the array as no-padding zero hexadecimal encoded string,
> + *   or the value is stored as padding zero to specified hexadecimal width.
> + * @return
> + *   0 on success, negative errno on error
> + */
> +__rte_experimental
> +int
> +rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
> +			       uint64_t val, uint8_t display_bitwidth);
> +
>  /**
>   * This telemetry callback is used when registering a telemetry command.
>   * It handles getting and formatting information to be returned to telemetry
> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
> index 34366ecee3..14cb56d680 100644
> --- a/lib/telemetry/telemetry_data.c
> +++ b/lib/telemetry/telemetry_data.c
> @@ -4,6 +4,7 @@
>  
>  #include <errno.h>
>  #include <stdlib.h>
> +#include <inttypes.h>
>  
>  #undef RTE_USE_LIBBSD
>  #include <stdbool.h>
> @@ -12,6 +13,8 @@
>  
>  #include "telemetry_data.h"
>  
> +#define RTE_TEL_UINT_HEX_STR_BUF_LEN 64
> +
>  int
>  rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
>  {
> @@ -97,6 +100,60 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
>  	return 0;
>  }
>  
> +/* To suppress compiler warning about format string. */
> +#if defined(RTE_TOOLCHAIN_GCC)
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> +#elif defined(RTE_TOOLCHAIN_CLANG)
> +#pragma clang diagnostic push
> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> +#endif
> +
> +static int
> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t val,
> +				uint8_t display_bitwidth)
> +{
> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> +
> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> +
> +	/* Buffer needs to have room to contain the prefix '0x' and '\0'. */
> +	if (len < spec_hex_width + 3)
> +		return -EINVAL;
> +
> +	if (display_bitwidth != 0) {
> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> +		sprintf(buf, format, val);
> +	} else {
> +		sprintf(buf, "0x%" PRIx64, val);
> +	}
> +
> +	return 0;
> +}
> +
> +#if defined(RTE_TOOLCHAIN_GCC)
> +#pragma GCC diagnostic pop
> +#elif defined(RTE_TOOLCHAIN_CLANG)
> +#pragma clang diagnostic pop
> +#endif
> +
> +int
> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
> +				uint8_t display_bitwidth)
> +{
> +	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
> +	int ret;
> +
> +	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
> +					      RTE_TEL_UINT_HEX_STR_BUF_LEN, val,
> +					      display_bitwidth);

Small nit - the indentation here - and in a few other places does not match
that in the rest of the file. The existing file only uses tabs for indent,
and does not align continuations on brackets, it just double-indents.

/Bruce

Re: [PATCH V5 5/8] mem: possible data truncation and conversion error

[lihuisong (C)]

在 2022/12/14 21:00, Morten Brørup 写道:
>> From: Huisong Li [mailto:lihuisong@huawei.com]
>> Sent: Wednesday, 14 December 2022 13.33
>>
>> The 'u32' and 'u64' data can not assigned to 'int' type variable.
>> They need to use the 'u64' APIs to add.
>>
>> Fixes: e6732d0d6e26 ("mem: add telemetry infos")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>>   lib/eal/common/eal_common_memory.c | 10 +++++-----
>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/lib/eal/common/eal_common_memory.c
>> b/lib/eal/common/eal_common_memory.c
>> index 688dc615d7..8e427bf4b4 100644
>> --- a/lib/eal/common/eal_common_memory.c
>> +++ b/lib/eal/common/eal_common_memory.c
>> @@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd
>> __rte_unused, const char *params,
>>   	malloc_heap_get_stats(heap, &sock_stats);
>>
>>   	rte_tel_data_start_dict(d);
>> -	rte_tel_data_add_dict_int(d, "Head id", heap_id);
>> +	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
> Consider: "Head id" -> "Heap_id"
Need to do this in this patch? Maybe it's better to do this in a new 
patch. What do you think?
>
>
>>   	rte_tel_data_add_dict_string(d, "Name", heap->name);
>>   	rte_tel_data_add_dict_u64(d, "Heap_size",
>>   				  sock_stats.heap_totalsz_bytes);
>> @@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd
>> __rte_unused,
>>   	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
>>
>>   	rte_tel_data_start_dict(d);
>> -	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
>> +	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
>>   	rte_tel_data_add_dict_string(d, "Name", mz->name);
>> -	rte_tel_data_add_dict_int(d, "Length", mz->len);
>> +	rte_tel_data_add_dict_u64(d, "Length", mz->len);
>>   	snprintf(addr, ADDR_STR, "%p", mz->addr);
>>   	rte_tel_data_add_dict_string(d, "Address", addr);
>>   	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
>> -	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
>> +	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
>>
>>   	/* go through each page occupied by this memzone */
>>   	msl = rte_mem_virt2memseg_list(mz->addr);
>> @@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd
>> __rte_unused,
>>   	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
>>   	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
>>
>> -	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
>> +	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
>>   	snprintf(addr, ADDR_STR, "%p", ms->addr);
>>   	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
>>
>> --
>> 2.33.0
>>

Re: [PATCH V5 6/8] telemetry: support adding integer value as hexadecimal

[lihuisong (C)]

在 2022/12/14 23:38, Bruce Richardson 写道:
> On Wed, Dec 14, 2022 at 08:32:51PM +0800, Huisong Li wrote:
>> Sometimes displaying a unsigned integer value as hexadecimal encoded style
>> is more expected for human consumption, such as, offload capability and
>> device flag. This patch introduces two APIs to add unsigned integer value
>> as hexadecimal encoded string to array or dictionary. And user can choose
>> whether the stored value is padding to the specified width.
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>>   lib/telemetry/rte_telemetry.h  | 47 +++++++++++++++++++++
>>   lib/telemetry/telemetry_data.c | 74 ++++++++++++++++++++++++++++++++++
>>   lib/telemetry/version.map      |  9 +++++
>>   3 files changed, 130 insertions(+)
>>
>> diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
>> index 40e9a3bf9d..b24f0310ea 100644
>> --- a/lib/telemetry/rte_telemetry.h
>> +++ b/lib/telemetry/rte_telemetry.h
>> @@ -10,6 +10,7 @@ extern "C" {
>>   #endif
>>   
>>   #include <stdint.h>
>> +#include <rte_compat.h>
>>   
>>   /** Maximum length for string used in object. */
>>   #define RTE_TEL_MAX_STRING_LEN 128
>> @@ -153,6 +154,28 @@ int
>>   rte_tel_data_add_array_container(struct rte_tel_data *d,
>>   		struct rte_tel_data *val, int keep);
>>   
>> +/**
>> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
>> + * to an array.
>> + * The array must have been started by rte_tel_data_start_array() with
>> + * RTE_TEL_STRING_VAL as the type parameter.
>> + *
>> + * @param d
>> + *   The data structure passed to the callback
>> + * @param val
>> + *   The number to be returned in the array as a hexadecimal encoded strings.
>> + * @param display_bitwidth
>> + *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
>> + *   value is stored in the array as no-padding zero hexadecimal encoded string,
>> + *   or the value is stored as padding zero to specified hexadecimal width.
>> + * @return
>> + *   0 on success, negative errno on error
>> + */
>> +__rte_experimental
>> +int
>> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
>> +				uint8_t display_bitwidth);
>> +
>>   /**
>>    * Add a string value to a dictionary.
>>    * The dict must have been started by rte_tel_data_start_dict().
>> @@ -231,6 +254,30 @@ int
>>   rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
>>   		struct rte_tel_data *val, int keep);
>>   
>> +/**
>> + * Convert a unsigned integer to hexadecimal encoded strings and add this string
>> + * to an dictionary.
>> + * The dict must have been started by rte_tel_data_start_dict().
>> + *
>> + * @param d
>> + *   The data structure passed to the callback
>> + * @param name
>> + *   The name of the value is to be stored in the dict
>> + *   Must contain only alphanumeric characters or the symbols: '_' or '/'
>> + * @param val
>> + *   The number to be stored in the dict as a hexadecimal encoded strings.
>> + * @param display_bitwidth
>> + *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
>> + *   value is stored in the array as no-padding zero hexadecimal encoded string,
>> + *   or the value is stored as padding zero to specified hexadecimal width.
>> + * @return
>> + *   0 on success, negative errno on error
>> + */
>> +__rte_experimental
>> +int
>> +rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
>> +			       uint64_t val, uint8_t display_bitwidth);
>> +
>>   /**
>>    * This telemetry callback is used when registering a telemetry command.
>>    * It handles getting and formatting information to be returned to telemetry
>> diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
>> index 34366ecee3..14cb56d680 100644
>> --- a/lib/telemetry/telemetry_data.c
>> +++ b/lib/telemetry/telemetry_data.c
>> @@ -4,6 +4,7 @@
>>   
>>   #include <errno.h>
>>   #include <stdlib.h>
>> +#include <inttypes.h>
>>   
>>   #undef RTE_USE_LIBBSD
>>   #include <stdbool.h>
>> @@ -12,6 +13,8 @@
>>   
>>   #include "telemetry_data.h"
>>   
>> +#define RTE_TEL_UINT_HEX_STR_BUF_LEN 64
>> +
>>   int
>>   rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
>>   {
>> @@ -97,6 +100,60 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
>>   	return 0;
>>   }
>>   
>> +/* To suppress compiler warning about format string. */
>> +#if defined(RTE_TOOLCHAIN_GCC)
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
>> +#elif defined(RTE_TOOLCHAIN_CLANG)
>> +#pragma clang diagnostic push
>> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
>> +#endif
>> +
>> +static int
>> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t val,
>> +				uint8_t display_bitwidth)
>> +{
>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
>> +
>> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
>> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
>> +
>> +	/* Buffer needs to have room to contain the prefix '0x' and '\0'. */
>> +	if (len < spec_hex_width + 3)
>> +		return -EINVAL;
>> +
>> +	if (display_bitwidth != 0) {
>> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
>> +		sprintf(buf, format, val);
>> +	} else {
>> +		sprintf(buf, "0x%" PRIx64, val);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +#if defined(RTE_TOOLCHAIN_GCC)
>> +#pragma GCC diagnostic pop
>> +#elif defined(RTE_TOOLCHAIN_CLANG)
>> +#pragma clang diagnostic pop
>> +#endif
>> +
>> +int
>> +rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
>> +				uint8_t display_bitwidth)
>> +{
>> +	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
>> +	int ret;
>> +
>> +	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
>> +					      RTE_TEL_UINT_HEX_STR_BUF_LEN, val,
>> +					      display_bitwidth);
> Small nit - the indentation here - and in a few other places does not match
> that in the rest of the file. The existing file only uses tabs for indent,
> and does not align continuations on brackets, it just double-indents.
All right. Let's keep it in line with the file.
>
> /Bruce
> .

RE: [PATCH V5 5/8] mem: possible data truncation and conversion error

[Morten Brørup]

> From: lihuisong (C) [mailto:lihuisong@huawei.com]
> Sent: Thursday, 15 December 2022 02.12
> 
> 在 2022/12/14 21:00, Morten Brørup 写道:
> >> From: Huisong Li [mailto:lihuisong@huawei.com]
> >> Sent: Wednesday, 14 December 2022 13.33
> >>
> >> --- a/lib/eal/common/eal_common_memory.c
> >> +++ b/lib/eal/common/eal_common_memory.c
> >> @@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd
> >> __rte_unused, const char *params,
> >>   	malloc_heap_get_stats(heap, &sock_stats);
> >>
> >>   	rte_tel_data_start_dict(d);
> >> -	rte_tel_data_add_dict_int(d, "Head id", heap_id);
> >> +	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
> > Consider: "Head id" -> "Heap_id"
> Need to do this in this patch? Maybe it's better to do this in a new
> patch. What do you think?

You are right. It belongs in a different patch, not related to this series.

Re: [PATCH V5 5/8] mem: possible data truncation and conversion error

[lihuisong (C)]

在 2022/12/15 15:04, Morten Brørup 写道:
>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
>> Sent: Thursday, 15 December 2022 02.12
>>
>> 在 2022/12/14 21:00, Morten Brørup 写道:
>>>> From: Huisong Li [mailto:lihuisong@huawei.com]
>>>> Sent: Wednesday, 14 December 2022 13.33
>>>>
>>>> --- a/lib/eal/common/eal_common_memory.c
>>>> +++ b/lib/eal/common/eal_common_memory.c
>>>> @@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd
>>>> __rte_unused, const char *params,
>>>>    	malloc_heap_get_stats(heap, &sock_stats);
>>>>
>>>>    	rte_tel_data_start_dict(d);
>>>> -	rte_tel_data_add_dict_int(d, "Head id", heap_id);
>>>> +	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
>>> Consider: "Head id" -> "Heap_id"
>> Need to do this in this patch? Maybe it's better to do this in a new
>> patch. What do you think?
> You are right. It belongs in a different patch, not related to this series.
Yes, it isn't related to this series. I'll fix it after this series.
>

[PATCH V6 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v6: fix code alignment to keep in line with codes in the file
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  72 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 308 insertions(+), 30 deletions(-)

-- 
2.33.0

[PATCH V6 1/8] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is unconditional. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V6 2/8] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..a40d396677 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V6 3/8] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..950d01ffac 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u64(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u64(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u64(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u64(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u64(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u64(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u64(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u64(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u64(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V6 4/8] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data
needs to use the 'u64' APIs to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..515d0df5ce 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u64(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V6 5/8] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..8e427bf4b4 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a unsigned integer value as hexadecimal encoded style
is more expected for human consumption, such as, offload capability and
device flag. This patch introduces two APIs to add unsigned integer value
as hexadecimal encoded string to array or dictionary. And user can choose
whether the stored value is padding to the specified width.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 72 ++++++++++++++++++++++++++++++++++
 lib/telemetry/version.map      |  9 +++++
 3 files changed, 128 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..b24f0310ea 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -153,6 +154,28 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param val
+ *   The number to be returned in the array as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -231,6 +254,30 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name of the value is to be stored in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..2a4dcec30a 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,8 @@
 
 #include "telemetry_data.h"
 
+#define RTE_TEL_UINT_HEX_STR_BUF_LEN 64
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -97,6 +100,59 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+/* To suppress compiler warning about format string. */
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wformat-nonliteral"
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wformat-nonliteral"
+#endif
+
+static int
+rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t val,
+				uint8_t display_bitwidth)
+{
+#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
+
+	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
+	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
+
+	/* Buffer needs to have room to contain the prefix '0x' and '\0'. */
+	if (len < spec_hex_width + 3)
+		return -EINVAL;
+
+	if (display_bitwidth != 0) {
+		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
+		sprintf(buf, format, val);
+	} else {
+		sprintf(buf, "0x%" PRIx64, val);
+	}
+
+	return 0;
+}
+
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic pop
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic pop
+#endif
+
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+			RTE_TEL_UINT_HEX_STR_BUF_LEN, val, display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -204,6 +260,22 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+			RTE_TEL_UINT_HEX_STR_BUF_LEN, val, display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..951bd63974 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_uint_hex;
+	rte_tel_data_add_dict_uint_hex;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V6 7/8] test: add test cases for adding hex integer value API

[Huisong Li]

Add test cases for adding hexadecimal unsigned integer value API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..e930457f4d 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -209,6 +209,39 @@ test_case_add_dict_string(void)
 	return CHECK_OUTPUT("{\"dict_0\":\"aaaa\",\"dict_1\":\"bbbb\",\"dict_2\":\"cccc\",\"dict_3\":\"dddd\"}");
 }
 
+static int
+test_case_add_dict_uint_hex_padding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 8);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 16);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 32);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x08\",\"dict_1\":\"0x0088\",\"dict_2\":\"0x00000888\",\"dict_3\":\"0x0000000000008888\"}");
+}
+
+static int
+test_case_add_dict_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x8\",\"dict_1\":\"0x88\",\"dict_2\":\"0x888\",\"dict_3\":\"0x8888\"}");
+}
 
 static int
 test_dict_with_array_string_values(void)
@@ -232,6 +265,50 @@ test_dict_with_array_string_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[\"aaaa\"],\"dict_1\":[\"bbbb\"]}");
 }
 
+static int
+test_dict_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x00000888\"],\"dict_1\":[\"0x0000000000008888\"]}");
+}
+
+static int
+test_dict_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x888\"],\"dict_1\":[\"0x8888\"]}");
+}
+
 static int
 test_dict_with_dict_values(void)
 {
@@ -278,6 +355,47 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_array_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x00000888\"],[\"0x0000000000008888\"]]");
+}
+
+
+static int
+test_array_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x888\"],[\"0x8888\"]]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +407,30 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_uint_hex_padding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 8);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 16);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("[\"0x08\",\"0x0088\",\"0x00000888\",\"0x0000000000008888\"]");
+}
+
+static int
+test_case_array_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("[\"0x8\",\"0x88\",\"0x888\",\"0x8888\"]");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -429,15 +571,23 @@ telemetry_data_autotest(void)
 			test_simple_string,
 			test_case_array_string,
 			test_case_array_int, test_case_array_u64,
+			test_case_array_uint_hex_padding,
+			test_case_array_uint_hex_nopadding,
 			test_case_add_dict_int, test_case_add_dict_u64,
 			test_case_add_dict_string,
+			test_case_add_dict_uint_hex_padding,
+			test_case_add_dict_uint_hex_nopadding,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_dict_with_array_uint_hex_values_padding,
+			test_dict_with_array_uint_hex_values_nopadding,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_array_with_array_uint_hex_values_padding,
+			test_array_with_array_uint_hex_values_nopadding,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V6 8/8] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index a40d396677..3e3b7febaa 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,13 +6068,14 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
-			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
-			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
-			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	rte_tel_data_add_dict_uint_hex(d, "dev_flags",
+			eth_dev->data->dev_flags, 0);
+	rte_tel_data_add_dict_uint_hex(d, "rx_offloads",
+			eth_dev->data->dev_conf.rxmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "tx_offloads",
+			eth_dev->data->dev_conf.txmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "ethdev_rss_hf",
+			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf, 0);
 
 	return 0;
 }
-- 
2.33.0

Re: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Bruce Richardson]

On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
> Sometimes displaying a unsigned integer value as hexadecimal encoded style
> is more expected for human consumption, such as, offload capability and
> device flag. This patch introduces two APIs to add unsigned integer value
> as hexadecimal encoded string to array or dictionary. And user can choose
> whether the stored value is padding to the specified width.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
>  lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
>  lib/telemetry/telemetry_data.c | 72 ++++++++++++++++++++++++++++++++++
>  lib/telemetry/version.map      |  9 +++++
>  3 files changed, 128 insertions(+)
> 
<snip>
> +/* To suppress compiler warning about format string. */
> +#if defined(RTE_TOOLCHAIN_GCC)
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> +#elif defined(RTE_TOOLCHAIN_CLANG)
> +#pragma clang diagnostic push
> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> +#endif
> +
> +static int
> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t val,
> +				uint8_t display_bitwidth)
> +{
> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> +
> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> +
> +	/* Buffer needs to have room to contain the prefix '0x' and '\0'. */
> +	if (len < spec_hex_width + 3)
> +		return -EINVAL;
> +

This check is not sufficient, as display_bitwidth could be 0 for example,
and the actual printed number have up to 16 characters.

> +	if (display_bitwidth != 0) {
> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> +		sprintf(buf, format, val);
> +	} else {
> +		sprintf(buf, "0x%" PRIx64, val);
> +	}
> +

snprintf should always be used when printing to the buffer so as to avoid
overflow. The return value after snprintf should always be checked too.

Thanks,
/Bruce

Re: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[lihuisong (C)]

在 2022/12/15 18:46, Bruce Richardson 写道:
> On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
>> Sometimes displaying a unsigned integer value as hexadecimal encoded style
>> is more expected for human consumption, such as, offload capability and
>> device flag. This patch introduces two APIs to add unsigned integer value
>> as hexadecimal encoded string to array or dictionary. And user can choose
>> whether the stored value is padding to the specified width.
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
>>   lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
>>   lib/telemetry/telemetry_data.c | 72 ++++++++++++++++++++++++++++++++++
>>   lib/telemetry/version.map      |  9 +++++
>>   3 files changed, 128 insertions(+)
>>
> <snip>
>> +/* To suppress compiler warning about format string. */
>> +#if defined(RTE_TOOLCHAIN_GCC)
>> +#pragma GCC diagnostic push
>> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
>> +#elif defined(RTE_TOOLCHAIN_CLANG)
>> +#pragma clang diagnostic push
>> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
>> +#endif
>> +
>> +static int
>> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t val,
>> +				uint8_t display_bitwidth)
>> +{
>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
>> +
>> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
>> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
>> +
>> +	/* Buffer needs to have room to contain the prefix '0x' and '\0'. */
>> +	if (len < spec_hex_width + 3)
>> +		return -EINVAL;
>> +
> This check is not sufficient, as display_bitwidth could be 0 for example,
> and the actual printed number have up to 16 characters.
Yes, you are right. What do you think of the following check?

max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) : 
spec_hex_width;
if (len < max_hex_width + 3)
     return -EINVAL;
>
>> +	if (display_bitwidth != 0) {
>> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
>> +		sprintf(buf, format, val);
>> +	} else {
>> +		sprintf(buf, "0x%" PRIx64, val);
>> +	}
>> +
> snprintf should always be used when printing to the buffer so as to avoid
> overflow. The return value after snprintf should always be checked too.
If check for buffer is sufficient, can the return value of snprintf not 
be checked?
There are also many places in telemetry lib that are not checked for 
this return value.
Do you have any principles for this?
>
> Thanks,
> /Bruce
> .

RE: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Morten Brørup]

> From: lihuisong (C) [mailto:lihuisong@huawei.com]
> Sent: Thursday, 15 December 2022 12.28
> 
> 在 2022/12/15 18:46, Bruce Richardson 写道:
> > On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
> >> Sometimes displaying a unsigned integer value as hexadecimal encoded
> style
> >> is more expected for human consumption, such as, offload capability
> and
> >> device flag. This patch introduces two APIs to add unsigned integer
> value
> >> as hexadecimal encoded string to array or dictionary. And user can
> choose
> >> whether the stored value is padding to the specified width.
> >>
> >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> >> ---
> >>   lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
> >>   lib/telemetry/telemetry_data.c | 72
> ++++++++++++++++++++++++++++++++++
> >>   lib/telemetry/version.map      |  9 +++++
> >>   3 files changed, 128 insertions(+)
> >>
> > <snip>
> >> +/* To suppress compiler warning about format string. */
> >> +#if defined(RTE_TOOLCHAIN_GCC)
> >> +#pragma GCC diagnostic push
> >> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> >> +#elif defined(RTE_TOOLCHAIN_CLANG)
> >> +#pragma clang diagnostic push
> >> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> >> +#endif
> >> +
> >> +static int
> >> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t
> val,

The "len" parameter should be size_t or unsigned int, not uint16_t.

And as a personal preference, I would name it "buf_len" instead of "len".

> >> +				uint8_t display_bitwidth)
> >> +{
> >> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> >> +
> >> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> >> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> >> +
> >> +	/* Buffer needs to have room to contain the prefix '0x' and '\0'.
> */
> >> +	if (len < spec_hex_width + 3)
> >> +		return -EINVAL;
> >> +
> > This check is not sufficient, as display_bitwidth could be 0 for
> example,
> > and the actual printed number have up to 16 characters.
> Yes, you are right. What do you think of the following check?
> 
> max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
> spec_hex_width;
> if (len < max_hex_width + 3)
>      return -EINVAL;

LGTM.

> >
> >> +	if (display_bitwidth != 0) {
> >> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> >> +		sprintf(buf, format, val);

snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
snprintf(buf, len, format, val);

> >> +	} else {
> >> +		sprintf(buf, "0x%" PRIx64, val);

snprintf(buf, len, "0x%" PRIx64, val);

> >> +	}
> >> +
> > snprintf should always be used when printing to the buffer so as to
> avoid
> > overflow. The return value after snprintf should always be checked
> too.
> If check for buffer is sufficient, can the return value of snprintf not
> be checked?
> There are also many places in telemetry lib that are not checked for
> this return value.
> Do you have any principles for this?

You already check the buffer size before printf() into it, so I think it suffices. However, to keep automated code checkers happy, you could easily use snprintf() instead of printf(). (Sorry about not doing it in my example.)

I somewhat disagree with Bruce's suggestion to check the return value from snprintf() after checking that the buffer is large enough. It would be effectively dead code, which might cause some confusion. On the other hand, it might keep some automated code checkers happy. In this specific case here, I don't have a strong preference.

-Morten

Re: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Bruce Richardson]

On Thu, Dec 15, 2022 at 01:00:40PM +0100, Morten Brørup wrote:
> > From: lihuisong (C) [mailto:lihuisong@huawei.com]
> > Sent: Thursday, 15 December 2022 12.28
> > 
> > 在 2022/12/15 18:46, Bruce Richardson 写道:
> > > On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
> > >> Sometimes displaying a unsigned integer value as hexadecimal encoded
> > style
> > >> is more expected for human consumption, such as, offload capability
> > and
> > >> device flag. This patch introduces two APIs to add unsigned integer
> > value
> > >> as hexadecimal encoded string to array or dictionary. And user can
> > choose
> > >> whether the stored value is padding to the specified width.
> > >>
> > >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> > >> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > >> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> > >> ---
> > >>   lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
> > >>   lib/telemetry/telemetry_data.c | 72
> > ++++++++++++++++++++++++++++++++++
> > >>   lib/telemetry/version.map      |  9 +++++
> > >>   3 files changed, 128 insertions(+)
> > >>
> > > <snip>
> > >> +/* To suppress compiler warning about format string. */
> > >> +#if defined(RTE_TOOLCHAIN_GCC)
> > >> +#pragma GCC diagnostic push
> > >> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> > >> +#elif defined(RTE_TOOLCHAIN_CLANG)
> > >> +#pragma clang diagnostic push
> > >> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> > >> +#endif
> > >> +
> > >> +static int
> > >> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len, uint64_t
> > val,
> 
> The "len" parameter should be size_t or unsigned int, not uint16_t.
> 
> And as a personal preference, I would name it "buf_len" instead of "len".
> 
> > >> +				uint8_t display_bitwidth)
> > >> +{
> > >> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> > >> +
> > >> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> > >> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> > >> +
> > >> +	/* Buffer needs to have room to contain the prefix '0x' and '\0'.
> > */
> > >> +	if (len < spec_hex_width + 3)
> > >> +		return -EINVAL;
> > >> +
> > > This check is not sufficient, as display_bitwidth could be 0 for
> > example,
> > > and the actual printed number have up to 16 characters.
> > Yes, you are right. What do you think of the following check?
> > 
> > max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
> > spec_hex_width;
> > if (len < max_hex_width + 3)
> >      return -EINVAL;
> 
> LGTM.

That would work, but actually I think we should drop this check completely
- see comment below.

> 
> > >
> > >> +	if (display_bitwidth != 0) {
> > >> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> > >> +		sprintf(buf, format, val);
> 
> snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
> snprintf(buf, len, format, val);
> 
> > >> +	} else {
> > >> +		sprintf(buf, "0x%" PRIx64, val);
> 
> snprintf(buf, len, "0x%" PRIx64, val);
> 
> > >> +	}
> > >> +
> > > snprintf should always be used when printing to the buffer so as to
> > avoid
> > > overflow. The return value after snprintf should always be checked
> > too.
> > If check for buffer is sufficient, can the return value of snprintf not
> > be checked?
> > There are also many places in telemetry lib that are not checked for
> > this return value.
> > Do you have any principles for this?
> 
> You already check the buffer size before printf() into it, so I think it suffices. However, to keep automated code checkers happy, you could easily use snprintf() instead of printf(). (Sorry about not doing it in my example.)
> 
> I somewhat disagree with Bruce's suggestion to check the return value from snprintf() after checking that the buffer is large enough. It would be effectively dead code, which might cause some confusion. On the other hand, it might keep some automated code checkers happy. In this specific case here, I don't have a strong preference.
> 
Sure, you don't need 2 checks - we can either check the length at the
start, or else check the length by looking for the return value from
snprintf, but we don't need to do both.

Given the slight complexity in determining the correct length of the printf
for the initial size check, I think I would go with the approach of *not*
checking the buffer initially and just check the snprintf return value.
That would remove any possibility of us doing an incorrect length check, as
was the case originally with this patch.

/Bruce

RE: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 15 December 2022 13.16
> 
> On Thu, Dec 15, 2022 at 01:00:40PM +0100, Morten Brørup wrote:
> > > From: lihuisong (C) [mailto:lihuisong@huawei.com]
> > > Sent: Thursday, 15 December 2022 12.28
> > >
> > > 在 2022/12/15 18:46, Bruce Richardson 写道:
> > > > On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
> > > >> Sometimes displaying a unsigned integer value as hexadecimal
> encoded
> > > style
> > > >> is more expected for human consumption, such as, offload
> capability
> > > and
> > > >> device flag. This patch introduces two APIs to add unsigned
> integer
> > > value
> > > >> as hexadecimal encoded string to array or dictionary. And user
> can
> > > choose
> > > >> whether the stored value is padding to the specified width.
> > > >>
> > > >> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> > > >> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > >> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> > > >> ---
> > > >>   lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
> > > >>   lib/telemetry/telemetry_data.c | 72
> > > ++++++++++++++++++++++++++++++++++
> > > >>   lib/telemetry/version.map      |  9 +++++
> > > >>   3 files changed, 128 insertions(+)
> > > >>
> > > > <snip>
> > > >> +/* To suppress compiler warning about format string. */
> > > >> +#if defined(RTE_TOOLCHAIN_GCC)
> > > >> +#pragma GCC diagnostic push
> > > >> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> > > >> +#elif defined(RTE_TOOLCHAIN_CLANG)
> > > >> +#pragma clang diagnostic push
> > > >> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> > > >> +#endif
> > > >> +
> > > >> +static int
> > > >> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len,
> uint64_t
> > > val,
> >
> > The "len" parameter should be size_t or unsigned int, not uint16_t.
> >
> > And as a personal preference, I would name it "buf_len" instead of
> "len".
> >
> > > >> +				uint8_t display_bitwidth)
> > > >> +{
> > > >> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> > > >> +
> > > >> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> > > >> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> > > >> +
> > > >> +	/* Buffer needs to have room to contain the prefix '0x' and
> '\0'.
> > > */
> > > >> +	if (len < spec_hex_width + 3)
> > > >> +		return -EINVAL;
> > > >> +
> > > > This check is not sufficient, as display_bitwidth could be 0 for
> > > example,
> > > > and the actual printed number have up to 16 characters.
> > > Yes, you are right. What do you think of the following check?
> > >
> > > max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
> > > spec_hex_width;
> > > if (len < max_hex_width + 3)
> > >      return -EINVAL;
> >
> > LGTM.
> 
> That would work, but actually I think we should drop this check
> completely
> - see comment below.
> 
> >
> > > >
> > > >> +	if (display_bitwidth != 0) {
> > > >> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> > > >> +		sprintf(buf, format, val);
> >
> > snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
> > snprintf(buf, len, format, val);
> >
> > > >> +	} else {
> > > >> +		sprintf(buf, "0x%" PRIx64, val);
> >
> > snprintf(buf, len, "0x%" PRIx64, val);
> >
> > > >> +	}
> > > >> +
> > > > snprintf should always be used when printing to the buffer so as
> to
> > > avoid
> > > > overflow. The return value after snprintf should always be
> checked
> > > too.
> > > If check for buffer is sufficient, can the return value of snprintf
> not
> > > be checked?
> > > There are also many places in telemetry lib that are not checked
> for
> > > this return value.
> > > Do you have any principles for this?
> >
> > You already check the buffer size before printf() into it, so I think
> it suffices. However, to keep automated code checkers happy, you could
> easily use snprintf() instead of printf(). (Sorry about not doing it in
> my example.)
> >
> > I somewhat disagree with Bruce's suggestion to check the return value
> from snprintf() after checking that the buffer is large enough. It
> would be effectively dead code, which might cause some confusion. On
> the other hand, it might keep some automated code checkers happy. In
> this specific case here, I don't have a strong preference.
> >
> Sure, you don't need 2 checks - we can either check the length at the
> start, or else check the length by looking for the return value from
> snprintf, but we don't need to do both.
> 
> Given the slight complexity in determining the correct length of the
> printf
> for the initial size check, I think I would go with the approach of
> *not*
> checking the buffer initially and just check the snprintf return value.
> That would remove any possibility of us doing an incorrect length
> check, as
> was the case originally with this patch.

That sounds reasonable to me. Please do that.

-Morten

Re: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[lihuisong (C)]

在 2022/12/15 20:24, Morten Brørup 写道:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Thursday, 15 December 2022 13.16
>>
>> On Thu, Dec 15, 2022 at 01:00:40PM +0100, Morten Brørup wrote:
>>>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
>>>> Sent: Thursday, 15 December 2022 12.28
>>>>
>>>> 在 2022/12/15 18:46, Bruce Richardson 写道:
>>>>> On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
>>>>>> Sometimes displaying a unsigned integer value as hexadecimal
>> encoded
>>>> style
>>>>>> is more expected for human consumption, such as, offload
>> capability
>>>> and
>>>>>> device flag. This patch introduces two APIs to add unsigned
>> integer
>>>> value
>>>>>> as hexadecimal encoded string to array or dictionary. And user
>> can
>>>> choose
>>>>>> whether the stored value is padding to the specified width.
>>>>>>
>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>>>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>>>>>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>>> ---
>>>>>>    lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
>>>>>>    lib/telemetry/telemetry_data.c | 72
>>>> ++++++++++++++++++++++++++++++++++
>>>>>>    lib/telemetry/version.map      |  9 +++++
>>>>>>    3 files changed, 128 insertions(+)
>>>>>>
>>>>> <snip>
>>>>>> +/* To suppress compiler warning about format string. */
>>>>>> +#if defined(RTE_TOOLCHAIN_GCC)
>>>>>> +#pragma GCC diagnostic push
>>>>>> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
>>>>>> +#elif defined(RTE_TOOLCHAIN_CLANG)
>>>>>> +#pragma clang diagnostic push
>>>>>> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
>>>>>> +#endif
>>>>>> +
>>>>>> +static int
>>>>>> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len,
>> uint64_t
>>>> val,
>>> The "len" parameter should be size_t or unsigned int, not uint16_t.
>>>
>>> And as a personal preference, I would name it "buf_len" instead of
>> "len".
>>>>>> +				uint8_t display_bitwidth)
>>>>>> +{
>>>>>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
>>>>>> +
>>>>>> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
>>>>>> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
>>>>>> +
>>>>>> +	/* Buffer needs to have room to contain the prefix '0x' and
>> '\0'.
>>>> */
>>>>>> +	if (len < spec_hex_width + 3)
>>>>>> +		return -EINVAL;
>>>>>> +
>>>>> This check is not sufficient, as display_bitwidth could be 0 for
>>>> example,
>>>>> and the actual printed number have up to 16 characters.
>>>> Yes, you are right. What do you think of the following check?
>>>>
>>>> max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
>>>> spec_hex_width;
>>>> if (len < max_hex_width + 3)
>>>>       return -EINVAL;
>>> LGTM.
>> That would work, but actually I think we should drop this check
>> completely
>> - see comment below.
>>
>>>>>> +	if (display_bitwidth != 0) {
>>>>>> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
>>>>>> +		sprintf(buf, format, val);
>>> snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
>>> snprintf(buf, len, format, val);
>>>
>>>>>> +	} else {
>>>>>> +		sprintf(buf, "0x%" PRIx64, val);
>>> snprintf(buf, len, "0x%" PRIx64, val);
>>>
>>>>>> +	}
>>>>>> +
>>>>> snprintf should always be used when printing to the buffer so as
>> to
>>>> avoid
>>>>> overflow. The return value after snprintf should always be
>> checked
>>>> too.
>>>> If check for buffer is sufficient, can the return value of snprintf
>> not
>>>> be checked?
>>>> There are also many places in telemetry lib that are not checked
>> for
>>>> this return value.
>>>> Do you have any principles for this?
>>> You already check the buffer size before printf() into it, so I think
>> it suffices. However, to keep automated code checkers happy, you could
>> easily use snprintf() instead of printf(). (Sorry about not doing it in
>> my example.)
>>> I somewhat disagree with Bruce's suggestion to check the return value
>> from snprintf() after checking that the buffer is large enough. It
>> would be effectively dead code, which might cause some confusion. On
>> the other hand, it might keep some automated code checkers happy. In
>> this specific case here, I don't have a strong preference.
>> Sure, you don't need 2 checks - we can either check the length at the
>> start, or else check the length by looking for the return value from
>> snprintf, but we don't need to do both.
>>
>> Given the slight complexity in determining the correct length of the
>> printf
>> for the initial size check, I think I would go with the approach of
>> *not*
>> checking the buffer initially and just check the snprintf return value.
>> That would remove any possibility of us doing an incorrect length
>> check, as
>> was the case originally with this patch.
> That sounds reasonable to me. Please do that.
I think above check is necessary. Because snprintf returns the total 
length of string
formated instead of negative when buffer size isn't sufficient. what do 
you think?

/Huisong

RE: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Morten Brørup]

> From: lihuisong (C) [mailto:lihuisong@huawei.com]
> Sent: Thursday, 15 December 2022 13.46
> 
> 在 2022/12/15 20:24, Morten Brørup 写道:
> >> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> >> Sent: Thursday, 15 December 2022 13.16
> >>
> >> On Thu, Dec 15, 2022 at 01:00:40PM +0100, Morten Brørup wrote:
> >>>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
> >>>> Sent: Thursday, 15 December 2022 12.28
> >>>>
> >>>> 在 2022/12/15 18:46, Bruce Richardson 写道:
> >>>>> On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
> >>>>>> Sometimes displaying a unsigned integer value as hexadecimal
> >> encoded
> >>>> style
> >>>>>> is more expected for human consumption, such as, offload
> >> capability
> >>>> and
> >>>>>> device flag. This patch introduces two APIs to add unsigned
> >> integer
> >>>> value
> >>>>>> as hexadecimal encoded string to array or dictionary. And user
> >> can
> >>>> choose
> >>>>>> whether the stored value is padding to the specified width.
> >>>>>>
> >>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> >>>>>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >>>>>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> >>>>>> ---
> >>>>>>    lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
> >>>>>>    lib/telemetry/telemetry_data.c | 72
> >>>> ++++++++++++++++++++++++++++++++++
> >>>>>>    lib/telemetry/version.map      |  9 +++++
> >>>>>>    3 files changed, 128 insertions(+)
> >>>>>>
> >>>>> <snip>
> >>>>>> +/* To suppress compiler warning about format string. */
> >>>>>> +#if defined(RTE_TOOLCHAIN_GCC)
> >>>>>> +#pragma GCC diagnostic push
> >>>>>> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> >>>>>> +#elif defined(RTE_TOOLCHAIN_CLANG)
> >>>>>> +#pragma clang diagnostic push
> >>>>>> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> >>>>>> +#endif
> >>>>>> +
> >>>>>> +static int
> >>>>>> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len,
> >> uint64_t
> >>>> val,
> >>> The "len" parameter should be size_t or unsigned int, not uint16_t.
> >>>
> >>> And as a personal preference, I would name it "buf_len" instead of
> >> "len".
> >>>>>> +				uint8_t display_bitwidth)
> >>>>>> +{
> >>>>>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> >>>>>> +
> >>>>>> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> >>>>>> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> >>>>>> +
> >>>>>> +	/* Buffer needs to have room to contain the prefix '0x' and
> >> '\0'.
> >>>> */
> >>>>>> +	if (len < spec_hex_width + 3)
> >>>>>> +		return -EINVAL;
> >>>>>> +
> >>>>> This check is not sufficient, as display_bitwidth could be 0 for
> >>>> example,
> >>>>> and the actual printed number have up to 16 characters.
> >>>> Yes, you are right. What do you think of the following check?
> >>>>
> >>>> max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
> >>>> spec_hex_width;
> >>>> if (len < max_hex_width + 3)
> >>>>       return -EINVAL;
> >>> LGTM.
> >> That would work, but actually I think we should drop this check
> >> completely
> >> - see comment below.
> >>
> >>>>>> +	if (display_bitwidth != 0) {
> >>>>>> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> >>>>>> +		sprintf(buf, format, val);
> >>> snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
> >>> snprintf(buf, len, format, val);
> >>>
> >>>>>> +	} else {
> >>>>>> +		sprintf(buf, "0x%" PRIx64, val);
> >>> snprintf(buf, len, "0x%" PRIx64, val);
> >>>
> >>>>>> +	}
> >>>>>> +
> >>>>> snprintf should always be used when printing to the buffer so as
> >> to
> >>>> avoid
> >>>>> overflow. The return value after snprintf should always be
> >> checked
> >>>> too.
> >>>> If check for buffer is sufficient, can the return value of
> snprintf
> >> not
> >>>> be checked?
> >>>> There are also many places in telemetry lib that are not checked
> >> for
> >>>> this return value.
> >>>> Do you have any principles for this?
> >>> You already check the buffer size before printf() into it, so I
> think
> >> it suffices. However, to keep automated code checkers happy, you
> could
> >> easily use snprintf() instead of printf(). (Sorry about not doing it
> in
> >> my example.)
> >>> I somewhat disagree with Bruce's suggestion to check the return
> value
> >> from snprintf() after checking that the buffer is large enough. It
> >> would be effectively dead code, which might cause some confusion. On
> >> the other hand, it might keep some automated code checkers happy. In
> >> this specific case here, I don't have a strong preference.
> >> Sure, you don't need 2 checks - we can either check the length at
> the
> >> start, or else check the length by looking for the return value from
> >> snprintf, but we don't need to do both.
> >>
> >> Given the slight complexity in determining the correct length of the
> >> printf
> >> for the initial size check, I think I would go with the approach of
> >> *not*
> >> checking the buffer initially and just check the snprintf return
> value.
> >> That would remove any possibility of us doing an incorrect length
> >> check, as
> >> was the case originally with this patch.
> > That sounds reasonable to me. Please do that.
> I think above check is necessary. Because snprintf returns the total
> length of string
> formated instead of negative when buffer size isn't sufficient. what do
> you think?

I had the same concern, so I looked it up.

snprintf() returns the length that the string would have, regardless if it was truncated or not.

In other words:

If the string is truncated, snprintf() returns a value greater than the buffer length parameter given to it.

It can be checked like this:

if (snprintf(buf, len, "0x%" PRIx64, val) > len)
    return -EINVAL;

In my opinion, checking for negative return values from snprintf() is not necessary.

Re: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[Bruce Richardson]

On Thu, Dec 15, 2022 at 01:52:02PM +0100, Morten Brørup wrote:
> > From: lihuisong (C) [mailto:lihuisong@huawei.com]
> > Sent: Thursday, 15 December 2022 13.46
> > 
> > 在 2022/12/15 20:24, Morten Brørup 写道:
> > >> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > >> Sent: Thursday, 15 December 2022 13.16
> > >>
> > >> On Thu, Dec 15, 2022 at 01:00:40PM +0100, Morten Brørup wrote:
> > >>>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
> > >>>> Sent: Thursday, 15 December 2022 12.28
> > >>>>
> > >>>> 在 2022/12/15 18:46, Bruce Richardson 写道:
> > >>>>> On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
> > >>>>>> Sometimes displaying a unsigned integer value as hexadecimal
> > >> encoded
> > >>>> style
> > >>>>>> is more expected for human consumption, such as, offload
> > >> capability
> > >>>> and
> > >>>>>> device flag. This patch introduces two APIs to add unsigned
> > >> integer
> > >>>> value
> > >>>>>> as hexadecimal encoded string to array or dictionary. And user
> > >> can
> > >>>> choose
> > >>>>>> whether the stored value is padding to the specified width.
> > >>>>>>
> > >>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> > >>>>>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > >>>>>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> > >>>>>> ---
> > >>>>>>    lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
> > >>>>>>    lib/telemetry/telemetry_data.c | 72
> > >>>> ++++++++++++++++++++++++++++++++++
> > >>>>>>    lib/telemetry/version.map      |  9 +++++
> > >>>>>>    3 files changed, 128 insertions(+)
> > >>>>>>
> > >>>>> <snip>
> > >>>>>> +/* To suppress compiler warning about format string. */
> > >>>>>> +#if defined(RTE_TOOLCHAIN_GCC)
> > >>>>>> +#pragma GCC diagnostic push
> > >>>>>> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
> > >>>>>> +#elif defined(RTE_TOOLCHAIN_CLANG)
> > >>>>>> +#pragma clang diagnostic push
> > >>>>>> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
> > >>>>>> +#endif
> > >>>>>> +
> > >>>>>> +static int
> > >>>>>> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len,
> > >> uint64_t
> > >>>> val,
> > >>> The "len" parameter should be size_t or unsigned int, not uint16_t.
> > >>>
> > >>> And as a personal preference, I would name it "buf_len" instead of
> > >> "len".
> > >>>>>> +				uint8_t display_bitwidth)
> > >>>>>> +{
> > >>>>>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
> > >>>>>> +
> > >>>>>> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
> > >>>>>> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
> > >>>>>> +
> > >>>>>> +	/* Buffer needs to have room to contain the prefix '0x' and
> > >> '\0'.
> > >>>> */
> > >>>>>> +	if (len < spec_hex_width + 3)
> > >>>>>> +		return -EINVAL;
> > >>>>>> +
> > >>>>> This check is not sufficient, as display_bitwidth could be 0 for
> > >>>> example,
> > >>>>> and the actual printed number have up to 16 characters.
> > >>>> Yes, you are right. What do you think of the following check?
> > >>>>
> > >>>> max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
> > >>>> spec_hex_width;
> > >>>> if (len < max_hex_width + 3)
> > >>>>       return -EINVAL;
> > >>> LGTM.
> > >> That would work, but actually I think we should drop this check
> > >> completely
> > >> - see comment below.
> > >>
> > >>>>>> +	if (display_bitwidth != 0) {
> > >>>>>> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
> > >>>>>> +		sprintf(buf, format, val);
> > >>> snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
> > >>> snprintf(buf, len, format, val);
> > >>>
> > >>>>>> +	} else {
> > >>>>>> +		sprintf(buf, "0x%" PRIx64, val);
> > >>> snprintf(buf, len, "0x%" PRIx64, val);
> > >>>
> > >>>>>> +	}
> > >>>>>> +
> > >>>>> snprintf should always be used when printing to the buffer so as
> > >> to
> > >>>> avoid
> > >>>>> overflow. The return value after snprintf should always be
> > >> checked
> > >>>> too.
> > >>>> If check for buffer is sufficient, can the return value of
> > snprintf
> > >> not
> > >>>> be checked?
> > >>>> There are also many places in telemetry lib that are not checked
> > >> for
> > >>>> this return value.
> > >>>> Do you have any principles for this?
> > >>> You already check the buffer size before printf() into it, so I
> > think
> > >> it suffices. However, to keep automated code checkers happy, you
> > could
> > >> easily use snprintf() instead of printf(). (Sorry about not doing it
> > in
> > >> my example.)
> > >>> I somewhat disagree with Bruce's suggestion to check the return
> > value
> > >> from snprintf() after checking that the buffer is large enough. It
> > >> would be effectively dead code, which might cause some confusion. On
> > >> the other hand, it might keep some automated code checkers happy. In
> > >> this specific case here, I don't have a strong preference.
> > >> Sure, you don't need 2 checks - we can either check the length at
> > the
> > >> start, or else check the length by looking for the return value from
> > >> snprintf, but we don't need to do both.
> > >>
> > >> Given the slight complexity in determining the correct length of the
> > >> printf
> > >> for the initial size check, I think I would go with the approach of
> > >> *not*
> > >> checking the buffer initially and just check the snprintf return
> > value.
> > >> That would remove any possibility of us doing an incorrect length
> > >> check, as
> > >> was the case originally with this patch.
> > > That sounds reasonable to me. Please do that.
> > I think above check is necessary. Because snprintf returns the total
> > length of string
> > formated instead of negative when buffer size isn't sufficient. what do
> > you think?
> 
> I had the same concern, so I looked it up.
> 
> snprintf() returns the length that the string would have, regardless if it was truncated or not.
> 
> In other words:
> 
> If the string is truncated, snprintf() returns a value greater than the buffer length parameter given to it.
> 
> It can be checked like this:
> 
> if (snprintf(buf, len, "0x%" PRIx64, val) > len)
>     return -EINVAL;
> 
> In my opinion, checking for negative return values from snprintf() is not necessary.
>
+1
One nit, because of the \0, we need to check for ">=" len since a return val
equal to length means the last character was truncated to make room for the
\0.

/Bruce

Re: [PATCH V6 6/8] telemetry: support adding integer value as hexadecimal

[lihuisong (C)]

在 2022/12/15 21:08, Bruce Richardson 写道:
> On Thu, Dec 15, 2022 at 01:52:02PM +0100, Morten Brørup wrote:
>>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
>>> Sent: Thursday, 15 December 2022 13.46
>>>
>>> 在 2022/12/15 20:24, Morten Brørup 写道:
>>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>>>> Sent: Thursday, 15 December 2022 13.16
>>>>>
>>>>> On Thu, Dec 15, 2022 at 01:00:40PM +0100, Morten Brørup wrote:
>>>>>>> From: lihuisong (C) [mailto:lihuisong@huawei.com]
>>>>>>> Sent: Thursday, 15 December 2022 12.28
>>>>>>>
>>>>>>> 在 2022/12/15 18:46, Bruce Richardson 写道:
>>>>>>>> On Thu, Dec 15, 2022 at 06:31:44PM +0800, Huisong Li wrote:
>>>>>>>>> Sometimes displaying a unsigned integer value as hexadecimal
>>>>> encoded
>>>>>>> style
>>>>>>>>> is more expected for human consumption, such as, offload
>>>>> capability
>>>>>>> and
>>>>>>>>> device flag. This patch introduces two APIs to add unsigned
>>>>> integer
>>>>>>> value
>>>>>>>>> as hexadecimal encoded string to array or dictionary. And user
>>>>> can
>>>>>>> choose
>>>>>>>>> whether the stored value is padding to the specified width.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>>>>>>>>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>>>>>>>>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>>>>>> ---
>>>>>>>>>     lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
>>>>>>>>>     lib/telemetry/telemetry_data.c | 72
>>>>>>> ++++++++++++++++++++++++++++++++++
>>>>>>>>>     lib/telemetry/version.map      |  9 +++++
>>>>>>>>>     3 files changed, 128 insertions(+)
>>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>> +/* To suppress compiler warning about format string. */
>>>>>>>>> +#if defined(RTE_TOOLCHAIN_GCC)
>>>>>>>>> +#pragma GCC diagnostic push
>>>>>>>>> +#pragma GCC diagnostic ignored "-Wformat-nonliteral"
>>>>>>>>> +#elif defined(RTE_TOOLCHAIN_CLANG)
>>>>>>>>> +#pragma clang diagnostic push
>>>>>>>>> +#pragma clang diagnostic ignored "-Wformat-nonliteral"
>>>>>>>>> +#endif
>>>>>>>>> +
>>>>>>>>> +static int
>>>>>>>>> +rte_tel_uint_to_hex_encoded_str(char *buf, uint16_t len,
>>>>> uint64_t
>>>>>>> val,
>>>>>> The "len" parameter should be size_t or unsigned int, not uint16_t.
>>>>>>
>>>>>> And as a personal preference, I would name it "buf_len" instead of
>>>>> "len".
>>>>>>>>> +				uint8_t display_bitwidth)
>>>>>>>>> +{
>>>>>>>>> +#define RTE_TEL_UINT_HEX_FORMAT_LEN 16
>>>>>>>>> +
>>>>>>>>> +	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
>>>>>>>>> +	char format[RTE_TEL_UINT_HEX_FORMAT_LEN];
>>>>>>>>> +
>>>>>>>>> +	/* Buffer needs to have room to contain the prefix '0x' and
>>>>> '\0'.
>>>>>>> */
>>>>>>>>> +	if (len < spec_hex_width + 3)
>>>>>>>>> +		return -EINVAL;
>>>>>>>>> +
>>>>>>>> This check is not sufficient, as display_bitwidth could be 0 for
>>>>>>> example,
>>>>>>>> and the actual printed number have up to 16 characters.
>>>>>>> Yes, you are right. What do you think of the following check?
>>>>>>>
>>>>>>> max_hex_width = display_bitwidth == 0 ? (sizeof(uint64_t) * 2) :
>>>>>>> spec_hex_width;
>>>>>>> if (len < max_hex_width + 3)
>>>>>>>        return -EINVAL;
>>>>>> LGTM.
>>>>> That would work, but actually I think we should drop this check
>>>>> completely
>>>>> - see comment below.
>>>>>
>>>>>>>>> +	if (display_bitwidth != 0) {
>>>>>>>>> +		sprintf(format, "0x%%0%u" PRIx64, spec_hex_width);
>>>>>>>>> +		sprintf(buf, format, val);
>>>>>> snprintf(format, sizeof(format), "0x%%0%u" PRIx64, spec_hex_width);
>>>>>> snprintf(buf, len, format, val);
>>>>>>
>>>>>>>>> +	} else {
>>>>>>>>> +		sprintf(buf, "0x%" PRIx64, val);
>>>>>> snprintf(buf, len, "0x%" PRIx64, val);
>>>>>>
>>>>>>>>> +	}
>>>>>>>>> +
>>>>>>>> snprintf should always be used when printing to the buffer so as
>>>>> to
>>>>>>> avoid
>>>>>>>> overflow. The return value after snprintf should always be
>>>>> checked
>>>>>>> too.
>>>>>>> If check for buffer is sufficient, can the return value of
>>> snprintf
>>>>> not
>>>>>>> be checked?
>>>>>>> There are also many places in telemetry lib that are not checked
>>>>> for
>>>>>>> this return value.
>>>>>>> Do you have any principles for this?
>>>>>> You already check the buffer size before printf() into it, so I
>>> think
>>>>> it suffices. However, to keep automated code checkers happy, you
>>> could
>>>>> easily use snprintf() instead of printf(). (Sorry about not doing it
>>> in
>>>>> my example.)
>>>>>> I somewhat disagree with Bruce's suggestion to check the return
>>> value
>>>>> from snprintf() after checking that the buffer is large enough. It
>>>>> would be effectively dead code, which might cause some confusion. On
>>>>> the other hand, it might keep some automated code checkers happy. In
>>>>> this specific case here, I don't have a strong preference.
>>>>> Sure, you don't need 2 checks - we can either check the length at
>>> the
>>>>> start, or else check the length by looking for the return value from
>>>>> snprintf, but we don't need to do both.
>>>>>
>>>>> Given the slight complexity in determining the correct length of the
>>>>> printf
>>>>> for the initial size check, I think I would go with the approach of
>>>>> *not*
>>>>> checking the buffer initially and just check the snprintf return
>>> value.
>>>>> That would remove any possibility of us doing an incorrect length
>>>>> check, as
>>>>> was the case originally with this patch.
>>>> That sounds reasonable to me. Please do that.
>>> I think above check is necessary. Because snprintf returns the total
>>> length of string
>>> formated instead of negative when buffer size isn't sufficient. what do
>>> you think?
>> I had the same concern, so I looked it up.
>>
>> snprintf() returns the length that the string would have, regardless if it was truncated or not.
>>
>> In other words:
>>
>> If the string is truncated, snprintf() returns a value greater than the buffer length parameter given to it.
>>
>> It can be checked like this:
>>
>> if (snprintf(buf, len, "0x%" PRIx64, val) > len)
>>      return -EINVAL;
>>
>> In my opinion, checking for negative return values from snprintf() is not necessary.
>>
> +1
> One nit, because of the \0, we need to check for ">=" len since a return val
> equal to length means the last character was truncated to make room for the
> \0.
ok, do this in this way.

[PATCH V7 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v7: replace sprintf with snprintf in patch 6/8
 -v6: fix code alignment to keep in line with codes in the file
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 309 insertions(+), 30 deletions(-)

-- 
2.33.0

[PATCH V7 1/8] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is unconditional. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V7 2/8] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..a40d396677 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V7 3/8] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..950d01ffac 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u64(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u64(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u64(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u64(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u64(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u64(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u64(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u64(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u64(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V7 4/8] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data
needs to use the 'u64' APIs to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..515d0df5ce 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u64(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V7 5/8] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..8e427bf4b4 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V7 6/8] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a unsigned integer value as hexadecimal encoded style
is more expected for human consumption, such as, offload capability and
device flag. This patch introduces two APIs to add unsigned integer value
as hexadecimal encoded string to array or dictionary. And user can choose
whether the stored value is padding to the specified width.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 73 ++++++++++++++++++++++++++++++++++
 lib/telemetry/version.map      |  9 +++++
 3 files changed, 129 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..b24f0310ea 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -153,6 +154,28 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param val
+ *   The number to be returned in the array as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -231,6 +254,30 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name of the value is to be stored in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..c3f031ad59 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,8 @@
 
 #include "telemetry_data.h"
 
+#define RTE_TEL_UINT_HEX_STR_BUF_LEN 64
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -97,6 +100,60 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+/* To suppress compiler warning about format string. */
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wformat-nonliteral"
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wformat-nonliteral"
+#endif
+
+static int
+rte_tel_uint_to_hex_encoded_str(char *buf, size_t buf_len, uint64_t val,
+				uint8_t display_bitwidth)
+{
+#define RTE_TEL_HEX_FORMAT_LEN 16
+
+	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
+	char format[RTE_TEL_HEX_FORMAT_LEN];
+
+	if (display_bitwidth != 0) {
+		if (snprintf(format, RTE_TEL_HEX_FORMAT_LEN, "0x%%0%u" PRIx64,
+				spec_hex_width) >= RTE_TEL_HEX_FORMAT_LEN)
+			return -EINVAL;
+
+		if (snprintf(buf, buf_len, format, val) >= (int)buf_len)
+			return -EINVAL;
+	} else {
+		if (snprintf(buf, buf_len, "0x%" PRIx64, val) >= (int)buf_len)
+			return -EINVAL;
+	}
+
+	return 0;
+}
+
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic pop
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic pop
+#endif
+
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+			RTE_TEL_UINT_HEX_STR_BUF_LEN, val, display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -204,6 +261,22 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+			RTE_TEL_UINT_HEX_STR_BUF_LEN, val, display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..951bd63974 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_uint_hex;
+	rte_tel_data_add_dict_uint_hex;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V7 7/8] test: add test cases for adding hex integer value API

[Huisong Li]

Add test cases for adding hexadecimal unsigned integer value API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..e930457f4d 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -209,6 +209,39 @@ test_case_add_dict_string(void)
 	return CHECK_OUTPUT("{\"dict_0\":\"aaaa\",\"dict_1\":\"bbbb\",\"dict_2\":\"cccc\",\"dict_3\":\"dddd\"}");
 }
 
+static int
+test_case_add_dict_uint_hex_padding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 8);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 16);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 32);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x08\",\"dict_1\":\"0x0088\",\"dict_2\":\"0x00000888\",\"dict_3\":\"0x0000000000008888\"}");
+}
+
+static int
+test_case_add_dict_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				       (uint8_t)0x8, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				       (uint16_t)0x88, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				       (uint32_t)0x888, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				       (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x8\",\"dict_1\":\"0x88\",\"dict_2\":\"0x888\",\"dict_3\":\"0x8888\"}");
+}
 
 static int
 test_dict_with_array_string_values(void)
@@ -232,6 +265,50 @@ test_dict_with_array_string_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[\"aaaa\"],\"dict_1\":[\"bbbb\"]}");
 }
 
+static int
+test_dict_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x00000888\"],\"dict_1\":[\"0x0000000000008888\"]}");
+}
+
+static int
+test_dict_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x888\"],\"dict_1\":[\"0x8888\"]}");
+}
+
 static int
 test_dict_with_dict_values(void)
 {
@@ -278,6 +355,47 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_array_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x00000888\"],[\"0x0000000000008888\"]]");
+}
+
+
+static int
+test_array_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x888\"],[\"0x8888\"]]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +407,30 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_uint_hex_padding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 8);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 16);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("[\"0x08\",\"0x0088\",\"0x00000888\",\"0x0000000000008888\"]");
+}
+
+static int
+test_case_array_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("[\"0x8\",\"0x88\",\"0x888\",\"0x8888\"]");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -429,15 +571,23 @@ telemetry_data_autotest(void)
 			test_simple_string,
 			test_case_array_string,
 			test_case_array_int, test_case_array_u64,
+			test_case_array_uint_hex_padding,
+			test_case_array_uint_hex_nopadding,
 			test_case_add_dict_int, test_case_add_dict_u64,
 			test_case_add_dict_string,
+			test_case_add_dict_uint_hex_padding,
+			test_case_add_dict_uint_hex_nopadding,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_dict_with_array_uint_hex_values_padding,
+			test_dict_with_array_uint_hex_values_nopadding,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_array_with_array_uint_hex_values_padding,
+			test_array_with_array_uint_hex_values_nopadding,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V7 8/8] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index a40d396677..3e3b7febaa 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,13 +6068,14 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
-			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
-			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
-			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	rte_tel_data_add_dict_uint_hex(d, "dev_flags",
+			eth_dev->data->dev_flags, 0);
+	rte_tel_data_add_dict_uint_hex(d, "rx_offloads",
+			eth_dev->data->dev_conf.rxmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "tx_offloads",
+			eth_dev->data->dev_conf.txmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "ethdev_rss_hf",
+			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf, 0);
 
 	return 0;
 }
-- 
2.33.0

Re: [PATCH V7 7/8] test: add test cases for adding hex integer value API

[Bruce Richardson]

On Fri, Dec 16, 2022 at 09:54:27AM +0800, Huisong Li wrote:
> Add test cases for adding hexadecimal unsigned integer value API.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> ---

The coding style is still a little off for indentation, but otherwise ok.

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [PATCH V7 7/8] test: add test cases for adding hex integer value API

[lihuisong (C)]

在 2022/12/16 17:31, Bruce Richardson 写道:
> On Fri, Dec 16, 2022 at 09:54:27AM +0800, Huisong Li wrote:
>> Add test cases for adding hexadecimal unsigned integer value API.
>>
>> Signed-off-by: Huisong Li <lihuisong@huawei.com>
>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
>> ---
> The coding style is still a little off for indentation, but otherwise ok.
Ok. fix it in v8.
>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
>
> .

[PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[Huisong Li]

Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.

In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library. 

---
 -v8: fix the coding style in patch 7/8
 -v7: replace sprintf with snprintf in patch 6/8
 -v6: fix code alignment to keep in line with codes in the file
 -v5:
    - drop a refactor patch.
    - no limit the bit width for xxx_uint_hex API.
 -v4:
    - remove 'u32' value type.
    - add padding zero for hexadecimal value
 -v3: fix a misspelling mistake in commit log.
 -v2:
    - fix ABI break warning.
    - introduce two APIs to store u32 and u64 values as hexadecimal
      encoded strings. 

Huisong Li (8):
  telemetry: move to header to controllable range
  ethdev: fix possible data truncation and conversion error
  mempool: fix possible data truncation and conversion error
  cryptodev: fix possible data conversion error
  mem: possible data truncation and conversion error
  telemetry: support adding integer value as hexadecimal
  test: add test cases for adding hex integer value API
  ethdev: display capability values in hexadecimal format

 app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
 lib/cryptodev/rte_cryptodev.c      |   2 +-
 lib/eal/common/eal_common_memory.c |  10 +-
 lib/ethdev/rte_ethdev.c            |  19 ++--
 lib/mempool/rte_mempool.c          |  24 ++---
 lib/telemetry/rte_telemetry.h      |  52 +++++++++-
 lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
 lib/telemetry/version.map          |   9 ++
 8 files changed, 309 insertions(+), 30 deletions(-)

-- 
2.33.0

[PATCH V8 1/8] telemetry: move to header to controllable range

[Huisong Li]

The "stdint.h" header is outside '_RTE_TELEMETRY_H_' macro, which cause
this header is unconditional. So this patch moves this header to inside
'_RTE_TELEMETRY_H_'.

Fixes: 99a2dd955fba ("lib: remove librte_ prefix from directory names")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/telemetry/rte_telemetry.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index d9918c4e96..40e9a3bf9d 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -2,9 +2,6 @@
  * Copyright(c) 2018 Intel Corporation
  */
 
-#include <stdint.h>
-
-
 #ifndef _RTE_TELEMETRY_H_
 #define _RTE_TELEMETRY_H_
 
@@ -12,6 +9,8 @@
 extern "C" {
 #endif
 
+#include <stdint.h>
+
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
 /** Maximum length of string. */
-- 
2.33.0

[PATCH V8 2/8] ethdev: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 58b43c1ddfd1 ("ethdev: add telemetry endpoint for device info")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..a40d396677 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6037,9 +6037,9 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 			eth_dev->data->nb_tx_queues);
 	rte_tel_data_add_dict_int(d, "port_id", eth_dev->data->port_id);
 	rte_tel_data_add_dict_int(d, "mtu", eth_dev->data->mtu);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_size_min",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_size_min",
 			eth_dev->data->min_rx_buf_size);
-	rte_tel_data_add_dict_int(d, "rx_mbuf_alloc_fail",
+	rte_tel_data_add_dict_u64(d, "rx_mbuf_alloc_fail",
 			eth_dev->data->rx_mbuf_alloc_failed);
 	rte_ether_format_addr(mac_addr, sizeof(mac_addr),
 			eth_dev->data->mac_addrs);
@@ -6068,12 +6068,12 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_int(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_int(d, "rx_offloads",
+	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
+	rte_tel_data_add_dict_u64(d, "rx_offloads",
 			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_int(d, "tx_offloads",
+	rte_tel_data_add_dict_u64(d, "tx_offloads",
 			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_int(d, "ethdev_rss_hf",
+	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
 			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
 
 	return 0;
-- 
2.33.0

[PATCH V8 3/8] mempool: fix possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: 2f5c4025abb3 ("mempool: add telemetry endpoint")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/mempool/rte_mempool.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index f33f455790..950d01ffac 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -1500,27 +1500,27 @@ mempool_info_cb(struct rte_mempool *mp, void *arg)
 		return;
 
 	rte_tel_data_add_dict_string(info->d, "name", mp->name);
-	rte_tel_data_add_dict_int(info->d, "pool_id", mp->pool_id);
-	rte_tel_data_add_dict_int(info->d, "flags", mp->flags);
+	rte_tel_data_add_dict_u64(info->d, "pool_id", mp->pool_id);
+	rte_tel_data_add_dict_u64(info->d, "flags", mp->flags);
 	rte_tel_data_add_dict_int(info->d, "socket_id", mp->socket_id);
-	rte_tel_data_add_dict_int(info->d, "size", mp->size);
-	rte_tel_data_add_dict_int(info->d, "cache_size", mp->cache_size);
-	rte_tel_data_add_dict_int(info->d, "elt_size", mp->elt_size);
-	rte_tel_data_add_dict_int(info->d, "header_size", mp->header_size);
-	rte_tel_data_add_dict_int(info->d, "trailer_size", mp->trailer_size);
-	rte_tel_data_add_dict_int(info->d, "private_data_size",
+	rte_tel_data_add_dict_u64(info->d, "size", mp->size);
+	rte_tel_data_add_dict_u64(info->d, "cache_size", mp->cache_size);
+	rte_tel_data_add_dict_u64(info->d, "elt_size", mp->elt_size);
+	rte_tel_data_add_dict_u64(info->d, "header_size", mp->header_size);
+	rte_tel_data_add_dict_u64(info->d, "trailer_size", mp->trailer_size);
+	rte_tel_data_add_dict_u64(info->d, "private_data_size",
 				  mp->private_data_size);
 	rte_tel_data_add_dict_int(info->d, "ops_index", mp->ops_index);
-	rte_tel_data_add_dict_int(info->d, "populated_size",
+	rte_tel_data_add_dict_u64(info->d, "populated_size",
 				  mp->populated_size);
 
 	mz = mp->mz;
 	rte_tel_data_add_dict_string(info->d, "mz_name", mz->name);
-	rte_tel_data_add_dict_int(info->d, "mz_len", mz->len);
-	rte_tel_data_add_dict_int(info->d, "mz_hugepage_sz",
+	rte_tel_data_add_dict_u64(info->d, "mz_len", mz->len);
+	rte_tel_data_add_dict_u64(info->d, "mz_hugepage_sz",
 				  mz->hugepage_sz);
 	rte_tel_data_add_dict_int(info->d, "mz_socket_id", mz->socket_id);
-	rte_tel_data_add_dict_int(info->d, "mz_flags", mz->flags);
+	rte_tel_data_add_dict_u64(info->d, "mz_flags", mz->flags);
 }
 
 static int
-- 
2.33.0

[PATCH V8 4/8] cryptodev: fix possible data conversion error

[Huisong Li]

The 'u32' data can not assigned to 'int' type variable. The 'u32' data
needs to use the 'u64' APIs to add.

Fixes: d3d98f5ce9d0 ("cryptodev: support telemetry")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/cryptodev/rte_cryptodev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..515d0df5ce 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -2692,7 +2692,7 @@ cryptodev_handle_dev_info(const char *cmd __rte_unused,
 	rte_tel_data_start_dict(d);
 	rte_tel_data_add_dict_string(d, "device_name",
 		cryptodev_info.device->name);
-	rte_tel_data_add_dict_int(d, "max_nb_queue_pairs",
+	rte_tel_data_add_dict_u64(d, "max_nb_queue_pairs",
 		cryptodev_info.max_nb_queue_pairs);
 
 	return 0;
-- 
2.33.0

[PATCH V8 5/8] mem: possible data truncation and conversion error

[Huisong Li]

The 'u32' and 'u64' data can not assigned to 'int' type variable.
They need to use the 'u64' APIs to add.

Fixes: e6732d0d6e26 ("mem: add telemetry infos")
Cc: stable@dpdk.org

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/eal/common/eal_common_memory.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/eal/common/eal_common_memory.c b/lib/eal/common/eal_common_memory.c
index 688dc615d7..8e427bf4b4 100644
--- a/lib/eal/common/eal_common_memory.c
+++ b/lib/eal/common/eal_common_memory.c
@@ -1139,7 +1139,7 @@ handle_eal_heap_info_request(const char *cmd __rte_unused, const char *params,
 	malloc_heap_get_stats(heap, &sock_stats);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Head id", heap_id);
+	rte_tel_data_add_dict_u64(d, "Head id", heap_id);
 	rte_tel_data_add_dict_string(d, "Name", heap->name);
 	rte_tel_data_add_dict_u64(d, "Heap_size",
 				  sock_stats.heap_totalsz_bytes);
@@ -1201,13 +1201,13 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	mz = rte_fbarray_get(&mcfg->memzones, mz_idx);
 
 	rte_tel_data_start_dict(d);
-	rte_tel_data_add_dict_int(d, "Zone", mz_idx);
+	rte_tel_data_add_dict_u64(d, "Zone", mz_idx);
 	rte_tel_data_add_dict_string(d, "Name", mz->name);
-	rte_tel_data_add_dict_int(d, "Length", mz->len);
+	rte_tel_data_add_dict_u64(d, "Length", mz->len);
 	snprintf(addr, ADDR_STR, "%p", mz->addr);
 	rte_tel_data_add_dict_string(d, "Address", addr);
 	rte_tel_data_add_dict_int(d, "Socket", mz->socket_id);
-	rte_tel_data_add_dict_int(d, "Flags", mz->flags);
+	rte_tel_data_add_dict_u64(d, "Flags", mz->flags);
 
 	/* go through each page occupied by this memzone */
 	msl = rte_mem_virt2memseg_list(mz->addr);
@@ -1222,7 +1222,7 @@ handle_eal_memzone_info_request(const char *cmd __rte_unused,
 	ms_idx = RTE_PTR_DIFF(mz->addr, msl->base_va) / page_sz;
 	ms = rte_fbarray_get(&msl->memseg_arr, ms_idx);
 
-	rte_tel_data_add_dict_int(d, "Hugepage_size", page_sz);
+	rte_tel_data_add_dict_u64(d, "Hugepage_size", page_sz);
 	snprintf(addr, ADDR_STR, "%p", ms->addr);
 	rte_tel_data_add_dict_string(d, "Hugepage_base", addr);
 
-- 
2.33.0

[PATCH V8 6/8] telemetry: support adding integer value as hexadecimal

[Huisong Li]

Sometimes displaying a unsigned integer value as hexadecimal encoded style
is more expected for human consumption, such as, offload capability and
device flag. This patch introduces two APIs to add unsigned integer value
as hexadecimal encoded string to array or dictionary. And user can choose
whether the stored value is padding to the specified width.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/telemetry/rte_telemetry.h  | 47 ++++++++++++++++++++++
 lib/telemetry/telemetry_data.c | 73 ++++++++++++++++++++++++++++++++++
 lib/telemetry/version.map      |  9 +++++
 3 files changed, 129 insertions(+)

diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 40e9a3bf9d..b24f0310ea 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -10,6 +10,7 @@ extern "C" {
 #endif
 
 #include <stdint.h>
+#include <rte_compat.h>
 
 /** Maximum length for string used in object. */
 #define RTE_TEL_MAX_STRING_LEN 128
@@ -153,6 +154,28 @@ int
 rte_tel_data_add_array_container(struct rte_tel_data *d,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an array.
+ * The array must have been started by rte_tel_data_start_array() with
+ * RTE_TEL_STRING_VAL as the type parameter.
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param val
+ *   The number to be returned in the array as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth);
+
 /**
  * Add a string value to a dictionary.
  * The dict must have been started by rte_tel_data_start_dict().
@@ -231,6 +254,30 @@ int
 rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 		struct rte_tel_data *val, int keep);
 
+/**
+ * Convert a unsigned integer to hexadecimal encoded strings and add this string
+ * to an dictionary.
+ * The dict must have been started by rte_tel_data_start_dict().
+ *
+ * @param d
+ *   The data structure passed to the callback
+ * @param name
+ *   The name of the value is to be stored in the dict
+ *   Must contain only alphanumeric characters or the symbols: '_' or '/'
+ * @param val
+ *   The number to be stored in the dict as a hexadecimal encoded strings.
+ * @param display_bitwidth
+ *   The display bit width of the 'val'. If 'display_bitwidth' is zero, the
+ *   value is stored in the array as no-padding zero hexadecimal encoded string,
+ *   or the value is stored as padding zero to specified hexadecimal width.
+ * @return
+ *   0 on success, negative errno on error
+ */
+__rte_experimental
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth);
+
 /**
  * This telemetry callback is used when registering a telemetry command.
  * It handles getting and formatting information to be returned to telemetry
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 34366ecee3..c3f031ad59 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -4,6 +4,7 @@
 
 #include <errno.h>
 #include <stdlib.h>
+#include <inttypes.h>
 
 #undef RTE_USE_LIBBSD
 #include <stdbool.h>
@@ -12,6 +13,8 @@
 
 #include "telemetry_data.h"
 
+#define RTE_TEL_UINT_HEX_STR_BUF_LEN 64
+
 int
 rte_tel_data_start_array(struct rte_tel_data *d, enum rte_tel_value_type type)
 {
@@ -97,6 +100,60 @@ rte_tel_data_add_array_container(struct rte_tel_data *d,
 	return 0;
 }
 
+/* To suppress compiler warning about format string. */
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wformat-nonliteral"
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wformat-nonliteral"
+#endif
+
+static int
+rte_tel_uint_to_hex_encoded_str(char *buf, size_t buf_len, uint64_t val,
+				uint8_t display_bitwidth)
+{
+#define RTE_TEL_HEX_FORMAT_LEN 16
+
+	uint8_t spec_hex_width = (display_bitwidth + 3) / 4;
+	char format[RTE_TEL_HEX_FORMAT_LEN];
+
+	if (display_bitwidth != 0) {
+		if (snprintf(format, RTE_TEL_HEX_FORMAT_LEN, "0x%%0%u" PRIx64,
+				spec_hex_width) >= RTE_TEL_HEX_FORMAT_LEN)
+			return -EINVAL;
+
+		if (snprintf(buf, buf_len, format, val) >= (int)buf_len)
+			return -EINVAL;
+	} else {
+		if (snprintf(buf, buf_len, "0x%" PRIx64, val) >= (int)buf_len)
+			return -EINVAL;
+	}
+
+	return 0;
+}
+
+#if defined(RTE_TOOLCHAIN_GCC)
+#pragma GCC diagnostic pop
+#elif defined(RTE_TOOLCHAIN_CLANG)
+#pragma clang diagnostic pop
+#endif
+
+int
+rte_tel_data_add_array_uint_hex(struct rte_tel_data *d, uint64_t val,
+				uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+			RTE_TEL_UINT_HEX_STR_BUF_LEN, val, display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+	return rte_tel_data_add_array_string(d, hex_str);
+}
+
 static bool
 valid_name(const char *name)
 {
@@ -204,6 +261,22 @@ rte_tel_data_add_dict_container(struct rte_tel_data *d, const char *name,
 	return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
 }
 
+int
+rte_tel_data_add_dict_uint_hex(struct rte_tel_data *d, const char *name,
+			       uint64_t val, uint8_t display_bitwidth)
+{
+	char hex_str[RTE_TEL_UINT_HEX_STR_BUF_LEN];
+	int ret;
+
+	ret = rte_tel_uint_to_hex_encoded_str(hex_str,
+			RTE_TEL_UINT_HEX_STR_BUF_LEN, val, display_bitwidth);
+	if (ret != 0)
+		return ret;
+
+
+	return rte_tel_data_add_dict_string(d, name, hex_str);
+}
+
 struct rte_tel_data *
 rte_tel_data_alloc(void)
 {
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 9794f9ea20..951bd63974 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -1,3 +1,12 @@
+EXPERIMENTAL {
+	global:
+
+	rte_tel_data_add_array_uint_hex;
+	rte_tel_data_add_dict_uint_hex;
+
+	local: *;
+};
+
 DPDK_23 {
 	global:
 
-- 
2.33.0

[PATCH V8 7/8] test: add test cases for adding hex integer value API

[Huisong Li]

Add test cases for adding hexadecimal unsigned integer value API.

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)

diff --git a/app/test/test_telemetry_data.c b/app/test/test_telemetry_data.c
index d92667a527..5b6c801599 100644
--- a/app/test/test_telemetry_data.c
+++ b/app/test/test_telemetry_data.c
@@ -209,6 +209,39 @@ test_case_add_dict_string(void)
 	return CHECK_OUTPUT("{\"dict_0\":\"aaaa\",\"dict_1\":\"bbbb\",\"dict_2\":\"cccc\",\"dict_3\":\"dddd\"}");
 }
 
+static int
+test_case_add_dict_uint_hex_padding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				(uint8_t)0x8, 8);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				(uint16_t)0x88, 16);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				(uint32_t)0x888, 32);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				(uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x08\",\"dict_1\":\"0x0088\",\"dict_2\":\"0x00000888\",\"dict_3\":\"0x0000000000008888\"}");
+}
+
+static int
+test_case_add_dict_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_0",
+				(uint8_t)0x8, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_1",
+				(uint16_t)0x88, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_2",
+				(uint32_t)0x888, 0);
+	rte_tel_data_add_dict_uint_hex(&response_data, "dict_3",
+				(uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":\"0x8\",\"dict_1\":\"0x88\",\"dict_2\":\"0x888\",\"dict_3\":\"0x8888\"}");
+}
 
 static int
 test_dict_with_array_string_values(void)
@@ -232,6 +265,50 @@ test_dict_with_array_string_values(void)
 	return CHECK_OUTPUT("{\"dict_0\":[\"aaaa\"],\"dict_1\":[\"bbbb\"]}");
 }
 
+static int
+test_dict_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x00000888\"],\"dict_1\":[\"0x0000000000008888\"]}");
+}
+
+static int
+test_dict_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_dict(&response_data);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_dict_container(&response_data, "dict_0",
+					child_data, 0);
+	rte_tel_data_add_dict_container(&response_data, "dict_1",
+					child_data2, 0);
+
+	return CHECK_OUTPUT("{\"dict_0\":[\"0x888\"],\"dict_1\":[\"0x8888\"]}");
+}
+
 static int
 test_dict_with_dict_values(void)
 {
@@ -278,6 +355,47 @@ test_array_with_array_string_values(void)
 	return CHECK_OUTPUT("[[\"aaaa\"],[\"bbbb\"]]");
 }
 
+static int
+test_array_with_array_uint_hex_values_padding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 64);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x00000888\"],[\"0x0000000000008888\"]]");
+}
+
+
+static int
+test_array_with_array_uint_hex_values_nopadding(void)
+{
+	struct rte_tel_data *child_data = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data, RTE_TEL_STRING_VAL);
+
+	struct rte_tel_data *child_data2 = rte_tel_data_alloc();
+	rte_tel_data_start_array(child_data2, RTE_TEL_STRING_VAL);
+
+	rte_tel_data_start_array(&response_data, RTE_TEL_CONTAINER);
+
+	rte_tel_data_add_array_uint_hex(child_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(child_data2, (uint64_t)0x8888, 0);
+
+	rte_tel_data_add_array_container(&response_data, child_data, 0);
+	rte_tel_data_add_array_container(&response_data, child_data2, 0);
+
+	return CHECK_OUTPUT("[[\"0x888\"],[\"0x8888\"]]");
+}
+
 static int
 test_case_array_u64(void)
 {
@@ -289,6 +407,30 @@ test_case_array_u64(void)
 	return CHECK_OUTPUT("[0,1,2,3,4]");
 }
 
+static int
+test_case_array_uint_hex_padding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 8);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 16);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 32);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 64);
+
+	return CHECK_OUTPUT("[\"0x08\",\"0x0088\",\"0x00000888\",\"0x0000000000008888\"]");
+}
+
+static int
+test_case_array_uint_hex_nopadding(void)
+{
+	rte_tel_data_start_array(&response_data, RTE_TEL_STRING_VAL);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint8_t)0x8, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint16_t)0x88, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint32_t)0x888, 0);
+	rte_tel_data_add_array_uint_hex(&response_data, (uint64_t)0x8888, 0);
+
+	return CHECK_OUTPUT("[\"0x8\",\"0x88\",\"0x888\",\"0x8888\"]");
+}
+
 static int
 test_case_add_dict_u64(void)
 {
@@ -429,15 +571,23 @@ telemetry_data_autotest(void)
 			test_simple_string,
 			test_case_array_string,
 			test_case_array_int, test_case_array_u64,
+			test_case_array_uint_hex_padding,
+			test_case_array_uint_hex_nopadding,
 			test_case_add_dict_int, test_case_add_dict_u64,
 			test_case_add_dict_string,
+			test_case_add_dict_uint_hex_padding,
+			test_case_add_dict_uint_hex_nopadding,
 			test_dict_with_array_int_values,
 			test_dict_with_array_u64_values,
 			test_dict_with_array_string_values,
+			test_dict_with_array_uint_hex_values_padding,
+			test_dict_with_array_uint_hex_values_nopadding,
 			test_dict_with_dict_values,
 			test_array_with_array_int_values,
 			test_array_with_array_u64_values,
 			test_array_with_array_string_values,
+			test_array_with_array_uint_hex_values_padding,
+			test_array_with_array_uint_hex_values_nopadding,
 			test_string_char_escaping,
 			test_array_char_escaping,
 			test_dict_char_escaping,
-- 
2.33.0

[PATCH V8 8/8] ethdev: display capability values in hexadecimal format

[Huisong Li]

The 'dev_flags', 'rx_offloads', 'tx_offloads' and 'rss_hf' are better
displayed in hexadecimal format.

Like:
 -->old display by input /ethdev/info,0
      "dev_flags": 3,
      "rx_offloads": 524288,
      "tx_offloads": 65536,
      "ethdev_rss_hf": 9100

 --> now display
     "dev_flags": "0x3",
     "rx_offloads": "0x80000",
     "tx_offloads": "0x10000",
     "ethdev_rss_hf": "0x238c"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index a40d396677..3e3b7febaa 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -6068,13 +6068,14 @@ eth_dev_handle_port_info(const char *cmd __rte_unused,
 	rte_tel_data_add_dict_container(d, "rxq_state", rxq_state, 0);
 	rte_tel_data_add_dict_container(d, "txq_state", txq_state, 0);
 	rte_tel_data_add_dict_int(d, "numa_node", eth_dev->data->numa_node);
-	rte_tel_data_add_dict_u64(d, "dev_flags", eth_dev->data->dev_flags);
-	rte_tel_data_add_dict_u64(d, "rx_offloads",
-			eth_dev->data->dev_conf.rxmode.offloads);
-	rte_tel_data_add_dict_u64(d, "tx_offloads",
-			eth_dev->data->dev_conf.txmode.offloads);
-	rte_tel_data_add_dict_u64(d, "ethdev_rss_hf",
-			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf);
+	rte_tel_data_add_dict_uint_hex(d, "dev_flags",
+			eth_dev->data->dev_flags, 0);
+	rte_tel_data_add_dict_uint_hex(d, "rx_offloads",
+			eth_dev->data->dev_conf.rxmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "tx_offloads",
+			eth_dev->data->dev_conf.txmode.offloads, 0);
+	rte_tel_data_add_dict_uint_hex(d, "ethdev_rss_hf",
+			eth_dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf, 0);
 
 	return 0;
 }
-- 
2.33.0

Re: [PATCH V8 6/8] telemetry: support adding integer value as hexadecimal

[Bruce Richardson]

On Mon, Dec 19, 2022 at 03:06:46PM +0800, Huisong Li wrote:
> Sometimes displaying a unsigned integer value as hexadecimal encoded style
> is more expected for human consumption, such as, offload capability and
> device flag. This patch introduces two APIs to add unsigned integer value
> as hexadecimal encoded string to array or dictionary. And user can choose
> whether the stored value is padding to the specified width.
> 
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[lihuisong (C)]

Hi Ferruh and Andrew,

This patch series optimizes some codes and bug.
Can you take a look at this patch series?
If there are no other questions, can it be merged?

Best,
Huisong

在 2022/12/19 15:06, Huisong Li 写道:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation. This patch series uses 'u64' functions to
> do this.
>
> In addition, this patch series introduces two APIs to store unsigned
> integer values as hexadecimal encoded strings in telemetry library.
>
> ---
>   -v8: fix the coding style in patch 7/8
>   -v7: replace sprintf with snprintf in patch 6/8
>   -v6: fix code alignment to keep in line with codes in the file
>   -v5:
>      - drop a refactor patch.
>      - no limit the bit width for xxx_uint_hex API.
>   -v4:
>      - remove 'u32' value type.merg
>      - add padding zero for hexadecimal value
>   -v3: fix a misspelling mistake in commit log.
>   -v2:
>      - fix ABI break warning.
>      - introduce two APIs to store u32 and u64 values as hexadecimal
>        encoded strings.
>
> Huisong Li (8):
>    telemetry: move to header to controllable range
>    ethdev: fix possible data truncation and conversion error
>    mempool: fix possible data truncation and conversion error
>    cryptodev: fix possible data conversion error
>    mem: possible data truncation and conversion error
>    telemetry: support adding integer value as hexadecimal
>    test: add test cases for adding hex integer value API
>    ethdev: display capability values in hexadecimal format
>
>   app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
>   lib/cryptodev/rte_cryptodev.c      |   2 +-
>   lib/eal/common/eal_common_memory.c |  10 +-
>   lib/ethdev/rte_ethdev.c            |  19 ++--
>   lib/mempool/rte_mempool.c          |  24 ++---
>   lib/telemetry/rte_telemetry.h      |  52 +++++++++-
>   lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
>   lib/telemetry/version.map          |   9 ++
>   8 files changed, 309 insertions(+), 30 deletions(-)
>

Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[lihuisong (C)]

Kindly ping.

在 2023/1/16 20:06, lihuisong (C) 写道:
> Hi Ferruh and Andrew,
>
> This patch series optimizes some codes and bug.
> Can you take a look at this patch series?
> If there are no other questions, can it be merged?
>
> Best,
> Huisong
>
> 在 2022/12/19 15:06, Huisong Li 写道:
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation. This patch series uses 'u64' functions to
>> do this.
>>
>> In addition, this patch series introduces two APIs to store unsigned
>> integer values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>>   -v8: fix the coding style in patch 7/8
>>   -v7: replace sprintf with snprintf in patch 6/8
>>   -v6: fix code alignment to keep in line with codes in the file
>>   -v5:
>>      - drop a refactor patch.
>>      - no limit the bit width for xxx_uint_hex API.
>>   -v4:
>>      - remove 'u32' value type.merg
>>      - add padding zero for hexadecimal value
>>   -v3: fix a misspelling mistake in commit log.
>>   -v2:
>>      - fix ABI break warning.
>>      - introduce two APIs to store u32 and u64 values as hexadecimal
>>        encoded strings.
>>
>> Huisong Li (8):
>>    telemetry: move to header to controllable range
>>    ethdev: fix possible data truncation and conversion error
>>    mempool: fix possible data truncation and conversion error
>>    cryptodev: fix possible data conversion error
>>    mem: possible data truncation and conversion error
>>    telemetry: support adding integer value as hexadecimal
>>    test: add test cases for adding hex integer value API
>>    ethdev: display capability values in hexadecimal format
>>
>>   app/test/test_telemetry_data.c     | 150 +++++++++++++++++++++++++++++
>>   lib/cryptodev/rte_cryptodev.c      |   2 +-
>>   lib/eal/common/eal_common_memory.c |  10 +-
>>   lib/ethdev/rte_ethdev.c            |  19 ++--
>>   lib/mempool/rte_mempool.c          |  24 ++---
>>   lib/telemetry/rte_telemetry.h      |  52 +++++++++-
>>   lib/telemetry/telemetry_data.c     |  73 ++++++++++++++
>>   lib/telemetry/version.map          |   9 ++
>>   8 files changed, 309 insertions(+), 30 deletions(-)
>>
>
> .

Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API

[Thomas Monjalon]

> Huisong Li (8):
>   telemetry: move to header to controllable range
>   ethdev: fix possible data truncation and conversion error
>   mempool: fix possible data truncation and conversion error
>   cryptodev: fix possible data conversion error
>   mem: possible data truncation and conversion error
>   telemetry: support adding integer value as hexadecimal
>   test: add test cases for adding hex integer value API
>   ethdev: display capability values in hexadecimal format

Applied, thanks.