From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 71656A0543; Wed, 14 Dec 2022 03:44:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 13B6A4021D; Wed, 14 Dec 2022 03:44:20 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 2FEB14003F for ; Wed, 14 Dec 2022 03:44:17 +0100 (CET) Received: from kwepemm600004.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NX0696N63zRpGW; Wed, 14 Dec 2022 10:43:13 +0800 (CST) Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Wed, 14 Dec 2022 10:44:14 +0800 Message-ID: Date: Wed, 14 Dec 2022 10:44:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH V4 7/9] telemetry: support adding integer value as hexadecimal To: Bruce Richardson CC: , , , , , References: <20221208080540.62913-1-lihuisong@huawei.com> <20221213101512.39919-1-lihuisong@huawei.com> <20221213101512.39919-8-lihuisong@huawei.com> From: "lihuisong (C)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 在 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 >> Acked-by: Morten Brørup >> Acked-by: Chengwen Feng > 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 >> +#include >> >> /** 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 >> #include >> +#include >> >> #undef RTE_USE_LIBBSD >> #include >> @@ -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 >> > .