在 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 <lihuis...@huawei.com>
Acked-by: Morten Brørup <m...@smartsharesystems.com>
Acked-by: Chengwen Feng <fengcheng...@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
.
