在 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:lihuis...@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
.
