-----Original Message-----
From: Gowrishankar Muthukrishnan
Sent: Friday, July 30, 2021 5:38 PM
To: Bruce Richardson <redacted>
Cc: dev@dpdk.org; ciara.power@intel.com; Jerin Jacob Kollanukkaran
[off-list ref]; Kiran Kumar Kokkilagadda [off-list ref];
Nithin Kumar Dabilpuram [off-list ref]; Sunil Kumar Kori
[off-list ref]; Satha Koteswara Rao Kottidi
[off-list ref]
Subject: RE: [EXT] Re: [dpdk-dev] [v1, 1/3] telemetry: enable storing pointer
value

Hi Bruce,

quoted

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