[8/8] ethdev: telemetry convert capability related variable to hex

  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"

Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
 lib/ethdev/rte_ethdev.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)
  

+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).
  

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.

Regards,
/Bruce
  

在 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
> .