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 64223A00C3; Fri, 9 Dec 2022 04:07:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4899B40E03; Fri, 9 Dec 2022 04:07:16 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 0D871400D6 for ; Fri, 9 Dec 2022 04:07:13 +0100 (CET) Received: from kwepemm600004.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4NSwnH3QgZzqSXT; Fri, 9 Dec 2022 11:02:59 +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.31; Fri, 9 Dec 2022 11:07:10 +0800 Message-ID: <5fecd5c1-2871-4798-e2c1-cd54b8cdf8a0@huawei.com> Date: Fri, 9 Dec 2022 11:07:10 +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 8/8] ethdev: telemetry convert capability related variable to hex To: Bruce Richardson , =?UTF-8?Q?Morten_Br=c3=b8rup?= CC: , , , , , References: <20221208080540.62913-1-lihuisong@huawei.com> <20221208080540.62913-9-lihuisong@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35D87573@smartserver.smartshare.dk> 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/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 > .