From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id A5662A0540;
Tue, 13 Dec 2022 18:12:05 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 88F0840146;
Tue, 13 Dec 2022 18:12:05 +0100 (CET)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
by mails.dpdk.org (Postfix) with ESMTP id 93293400D5
for <dev@dpdk.org>; Tue, 13 Dec 2022 18:12:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1670951522; x=1702487522;
h=date:from:to:cc:subject:message-id:references:
content-transfer-encoding:in-reply-to:mime-version;
bh=jhX7o8k+9i2/H82Wkmp2ImtFfNeiKzDuCGJ2k7z9hcU=;
b=P0a6avpyIqLPxOuuOKGjaoyzHNdAQajOXYCgzxVW0Fzb+3cbvLCp4LVn
m2g8Lor1x4pCBpKZIk8H80ooeYSsdHigAxq0mXxlCIZ1O0PFLtJS5Yqmq
Gf3j6YC3LcXl0rdeHoo7+foKeOhYqpNcQbGZ+z9msi0Q1XGYBQi2MdrZe
AleBJXK7BbLSpaMeiex4FtMO3FDfHP7DNumPUTExbrYNOQVM/N+ovDmzx
Zz6mYgKJoIBoe8yrz9Ucsnx34xgVu0Gi00sDo1oafBKlj60+mM6h3KJ9u
OAg+ywfQ6iFXfC5wjSMuG2i/6l8ocjg8hvmRaQ1VTXc2KLGtTv0QFs+jX Q==;
X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="382484656"
X-IronPort-AV: E=Sophos;i="5.96,242,1665471600"; d="scan'208";a="382484656"
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
13 Dec 2022 09:09:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="977531051"
X-IronPort-AV: E=Sophos;i="5.96,242,1665471600"; d="scan'208";a="977531051"
Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14])
by fmsmga005.fm.intel.com with ESMTP; 13 Dec 2022 09:09:18 -0800
Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by
ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.16; Tue, 13 Dec 2022 09:09:18 -0800
Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by
ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.16; Tue, 13 Dec 2022 09:09:18 -0800
Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by
orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.16 via Frontend Transport; Tue, 13 Dec 2022 09:09:18 -0800
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by
edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.1.2507.16; Tue, 13 Dec 2022 09:09:17 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=fVST1Au4iATWahH4QrJKHf34z/KiJ1H8Esm69XdRvECTnjQcKKKQjblUlWd6j13D2D7u/9mpR0kd7NWjmz4P5LgP1LOkwlK0WYvVRXT9fqZ9hTmHKnwVYpTWrGUWVJWWtKlg4lw5LKElbvNPN2KVc3VwjA9+142W6DFM6pZkvXWY/AVJAJ7msckBR9j7aRbOI9+O7wCVZJ12qbq31/g/z6m62Y4qEgHlfB0J1QN3V9Iq6DUrfYwt+9YyBl4UjXMB4VsI4U4UdCKj8mj7RQyGkMFkhHe0qrc3jG3zBbnVvyr6f9qyMyPDwg1U6tcRKfOeU3F2IzeNRrWMHcZ0s6T9aQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=L8ZYgnq8J25xaUAQY3aQamyH7AVc+VPcKppwYLmHr/c=;
b=hNJMh86Cvopsbl+wro9Afxo1pN2ka704HI2H+lLhsRECkc9XPgtvDAelr3/bdqngAJUT38epbe330dSfvaFMnhfaWQeLh3wllhsraD0s8MsPeEbu82nefloW+4olWAyrPGHXQXOdHgN4Df39iJtjXeRHc2W/cNiygh0PgDVAZsZQ8S5SPiMVySehYH1Brprkm38HSO3CoIkgD9V25MCfzPsmoJFwSARAaKfiRRMmr91+cVBXyhZc4Myo8A3LqOTsBAvtrX66WT2/ZTqX+zMZrT6rvgkMYzhx9UKhC6m/HO2iz6+JW/vt1RXJ4fwTFajg1VTcPPB6M7HG4dgcx3uVRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=intel.com;
Received: from MWHPR11MB1629.namprd11.prod.outlook.com (2603:10b6:301:d::21)
by SJ0PR11MB4943.namprd11.prod.outlook.com (2603:10b6:a03:2ad::17) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.19; Tue, 13 Dec
2022 17:09:16 +0000
Received: from MWHPR11MB1629.namprd11.prod.outlook.com
([fe80::18bd:edae:ad31:a228]) by MWHPR11MB1629.namprd11.prod.outlook.com
([fe80::18bd:edae:ad31:a228%3]) with mapi id 15.20.5880.019; Tue, 13 Dec 2022
17:09:16 +0000
Date: Tue, 13 Dec 2022 17:09:10 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Huisong Li <lihuisong@huawei.com>
CC: <dev@dpdk.org>, <mb@smartsharesystems.com>,
<andrew.rybchenko@oktetlabs.ru>, <huangdaode@huawei.com>,
<liudongdong3@huawei.com>, <fengchengwen@huawei.com>
Subject: Re: [PATCH V4 7/9] telemetry: support adding integer value as
hexadecimal
Message-ID: <Y5ixtryyO/0u2nym@bricha3-MOBL.ger.corp.intel.com>
References: <20221208080540.62913-1-lihuisong@huawei.com>
<20221213101512.39919-1-lihuisong@huawei.com>
<20221213101512.39919-8-lihuisong@huawei.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20221213101512.39919-8-lihuisong@huawei.com>
X-ClientProxiedBy: LO4P265CA0067.GBRP265.PROD.OUTLOOK.COM
(2603:10a6:600:2af::17) To MWHPR11MB1629.namprd11.prod.outlook.com
(2603:10b6:301:d::21)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MWHPR11MB1629:EE_|SJ0PR11MB4943:EE_
X-MS-Office365-Filtering-Correlation-Id: f2ff1d18-4af5-4a6f-9704-08dadd2cc3cf
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: TnKE/ocQIP+twvmMfJH0W30isHIexst73qDNN/mZIR92y5DFU1nqwxcsbfBgYjVl+/72Cbg8mxAJlRl5Ls17dvoBFZVAmqDxlzjU3bNBzG89o/Rh8qB15oNe73A/ajh917Dhlni+OrWSv0IWLRCbo61TPY4bKOGBbZo6t0PLE7jlYw703JZ1w2sw4XuwuQvwKYtIvLaeq/2Ar4xdU5xn8t+5gj+fS2U8o6fuRVje/vOaznjLpo1z8d9Q8ds2jxuGf++3eUq30/D22PRtII4iy1TYOH+2BdMJvAoSnqlRPmPtP3XpVA77DPvC53fPLYLS16HWC6vB2j8pzyiH9z2ZMwgMfx1h7aQF0vhBdjhSKGLJPcQ0eUelD5541G4tL1tI4uRv0GLpnNY+AvoNSyE1WjKYSK7aFDeMuDdBKZtihYwQCvDDEMNISdG6kv/kWdDmrGSuk8BtzAWk62yNbi7VaNwo2EIvNeGUlk2xoM9UAkJYLiLm1DqF0dOnnYyNf0pb68YWF2I0xxB4sxYBto6kqhK4ZK0sR5hxSZddjJJgUsB4WZl0U3fCPJ+iOzO50QRyWEUq5DEIQtAIXTZpzl89KsSVFgUXQ+g+2mJh33i0QiU1caXYmpvSPWped6JwWWbWMceCgRUURS7hNw6KKE+nZw==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:MWHPR11MB1629.namprd11.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230022)(396003)(366004)(346002)(39860400002)(136003)(376002)(451199015)(316002)(6916009)(26005)(2906002)(6666004)(186003)(66946007)(66574015)(6512007)(478600001)(8936002)(83380400001)(44832011)(6486002)(38100700002)(82960400001)(5660300002)(86362001)(4326008)(66556008)(8676002)(41300700001)(66476007)(6506007);
DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?hOOGFfRhV+TCTFcII+VOMPECzQKGaxesiuqWTVHj2OismKMMVPa20HmYS/?=
=?iso-8859-1?Q?PqBtXX7I83+zILZpJpkA8Uk2TshIRhH+bu9IkL01YVbNbF8VOLRUQ4Z8E6?=
=?iso-8859-1?Q?JmXCr/FTjHjq7+zSJwpXHXL9bgb1IRNlRbpsIo42cG0eZ2biRMJNKZ3nAk?=
=?iso-8859-1?Q?yPdS3kH2wy/5+lyuJkMAJf/cEZ+SYvbxNw2UNuX+sk9dcVz5az/c2yVNCj?=
=?iso-8859-1?Q?DVDjWo+cIsKGgp/eguA43OpFq4UXv3UiCitchcAO+bQ9x8+xe+VoOd5984?=
=?iso-8859-1?Q?BCcXQX64i7Mez1OsfRiwkioyTlBxtVYv7WVqYvEje+Bms/nhTED0zUrpAI?=
=?iso-8859-1?Q?SVaxZhFzpLyeBJxLEOT5SQJoFQymJgl5H5VYh7GEJNdKhZfnbR7t1UZr0F?=
=?iso-8859-1?Q?bBqjCdi5BTnCh68UEhKp+XUpmVUzrIPZyotK3FKaBERqphVUCP/qFSalcG?=
=?iso-8859-1?Q?O6b4BS2EgAyU+Zb31iFBCt0KVyP1HDvyJuZIYEHIzDbZjmV9YbaSU8U5wW?=
=?iso-8859-1?Q?Aa46jO7cZo1es6KZvJjXu0h++tNM1Qgj6G9C3OOn/LtbhewZWJa0kfhU2H?=
=?iso-8859-1?Q?Ti8mrZ0I9eG+abUgY8f1jGoVct0z26kcEtMviQCiSoRRM20LuFSyBr+dLJ?=
=?iso-8859-1?Q?iG6dL9vco7JadJTRgKS1OL51+6D4zNDYRd0tjcM1dePXSDIZhalcazQj77?=
=?iso-8859-1?Q?nWo9d8sFD+4CZ3YYUbGUgSrNBXoY6mQw+bzhgUGOPMSMG+ziF/jLXIE86Q?=
=?iso-8859-1?Q?Qu13uHjy4mOHpp323WuuA8Hh+8eQMdy0nENrH/Kn6d0b7mJ0KIOdg3fPWw?=
=?iso-8859-1?Q?Vpgs+6yEZsl32pAkvJOTKwJpTFtIFMCz7UBGG9bwTXGhN3MLlSSR1ENrhV?=
=?iso-8859-1?Q?uVjOlgPS9fmHuX9l5Z18hcoOlo8BjdKXAb3TjcNJ3Zfyxdsn1D6flnbsFg?=
=?iso-8859-1?Q?ooFV0MwU+jqYFFK0ZMEEbqcSrR8rsaaDclM8F0FCvf8f3UEbdHSGp8BsKr?=
=?iso-8859-1?Q?h0/ysvpCeeTFLv+EvnLGWhtIPQsezxK+HNrWeJCzMv5sU68mjKMMveWci5?=
=?iso-8859-1?Q?VG9VUtl2/jsusXtVimKIaIwk0LqjPMT1jzNqHG0i6ydF3kz5OkOwQmgvb5?=
=?iso-8859-1?Q?soy6/OhMNAj6LLgy4Ye2+DCDYKZv0Ug+lPJe199oTd2gNehTrX9Pt4PfZ+?=
=?iso-8859-1?Q?hqnD7tdTin+kIFjGHaQh8UKgp3afvzpP2J4DKxx/uuafoabE1Via+ERA2x?=
=?iso-8859-1?Q?XhtvPyN7oLDX6ZC43sFtyZyVNvAjNbRa27djdlNnuk/W9as0npb5NhMMe6?=
=?iso-8859-1?Q?bfAQ5kNuhcOJfF2f1eTmq0hXSEak2u/A92MA+MQAn4UjeSfxSDl284Gmfh?=
=?iso-8859-1?Q?G0U/uiDPyKxUDRlHYjMc+vNSb6Utwv7s89/2N1v1Vb6CmMn50bT8jgPo0L?=
=?iso-8859-1?Q?ORUnjow168IsMtkvUW34e1HriNU6E7AzDiYKqVRNfoOrkiKcCREkaPlear?=
=?iso-8859-1?Q?ADdoWzHH1IrAURRk0Ky42Y446/1LedftIpdVmf3/K9L/Y157aryar1lR6O?=
=?iso-8859-1?Q?htkDYtZfsqShpLVDljvwRw9ELgNzcCipxBdDaJ+aMuFkVfI/fFNQFAfdy4?=
=?iso-8859-1?Q?NGnRUELrmsna5A9sCvVzuAHFna8Us5YIbnzGPSV1xmXFWkXrsPf8LLSg?=
=?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f2ff1d18-4af5-4a6f-9704-08dadd2cc3cf
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1629.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2022 17:09:16.1995 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RXw2/lBqPGja8OkShcPrBKIFRd1J2j99qanUV1yeXb9zEDY2vGJ6Xci23Ig+OiWigdPgYnvUw7wQpg67h1I8qisLulMrlykPh6YEyQVAaEs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4943
X-OriginatorOrg: intel.com
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
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
>