> -----Original Message-----
> From: Gowrishankar Muthukrishnan
> Sent: Friday, July 30, 2021 5:38 PM
> To: Bruce Richardson <bruce.richard...@intel.com>
> Cc: dev@dpdk.org; ciara.po...@intel.com; Jerin Jacob Kollanukkaran
> <jer...@marvell.com>; Kiran Kumar Kokkilagadda <kirankum...@marvell.com>;
> Nithin Kumar Dabilpuram <ndabilpu...@marvell.com>; Sunil Kumar Kori
> <sk...@marvell.com>; Satha Koteswara Rao Kottidi
> <skotesh...@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
