[dpdk-dev] [EXT] Re: [v1, 1/3] telemetry: enable storing pointer value

[Gowrishankar Muthukrishnan]

> -----Original Message-----
> From: Gowrishankar Muthukrishnan
> Sent: Friday, July 30, 2021 5:38 PM
> To: Bruce Richardson <bruce.richardson at intel.com>
> Cc: dev at dpdk.org; ciara.power at intel.com; Jerin Jacob Kollanukkaran
> <jerinj at marvell.com>; Kiran Kumar Kokkilagadda <kirankumark at marvell.com>;
> Nithin Kumar Dabilpuram <ndabilpuram at marvell.com>; Sunil Kumar Kori
> <skori at marvell.com>; Satha Koteswara Rao Kottidi
> <skoteshwar at marvell.com>
> Subject: RE: [EXT] Re: [dpdk-dev] [v1, 1/3] telemetry: enable storing pointer
> value
> 
> Hi Bruce,
> 
> > I'm a little curious as to the usefulness of having a pointer value in
> > telemetry output? How would a telemetry user be expected to use
> > pointer information returned? Printing pointers seems something more
> > useful for a debugging or tracing interface than a telemetry one.
> >
> 
> Thanks for the quick review. I enabled _ptr API keeping few things in mind:
> 
> 1. User need to explicitly type cast pointer value (ie address) to uint64_t
>     which otherwise can cause compiler warning (Wint-conversion). Although
>     u64 is large enough for holding address as value, type casting is problematic
>     for non-64 bit machines (eg 32 bit). One other option is to use uintptr_t
>     as a holder.
> 
Please check [v2].
I modified json encoding to uintptr instead of stringified hex as in current patch.
I think, this is better approach as pointer value is stored more correctly (void *)
as well as retrieved in JSON following uintptr_t cast. Also I think, this is architecture 
compliant approach rather than assuming pointer address is always 64 bit (and 
what if 128 bit comes alive - who knows when). Aim is to leave _ptr api 
architecture compliance anytime.

> 2. With this API, code walk could be easier as user can interpret the accessed
>      data better (ie ptr is address value). _ptr API is meant for pointer variables,
>      though it is up to user to choose.
> 
With above uintptr_t as encoded value, it does not change the client handling
as client would consume it as its architecture supported value (uint64_t).
One advantage of having this API is to support JSON5 compliance hex address
once decided so in future.

> 3. Also while debugging telemetry date using script like usertools/dpdk-
> telemetry.py,
>     perceiving address as hex is quicker than same as u64.
> 
> Answering on returned data, user needs to convert stringified hex to pointer
> value.
With uintptr_t value (in new patch), no change is needed in client side.

Please suggest.
Thanks,
Gowrishankar
> 
> Regards,
> Gowrishankar