Re: [EXT] Re: [PATCH v5 1/2] mem: telemetry support for memseg and element information

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

Hi Amit,

2022-10-21 19:26 (UTC+0000), Amit Prakash Shukla:
[...]
> > How does the user learn heap_id?
> > There probably should be /eal/heap_id returning a list of heap IDs.  
> 
> Request for list of active heap Id's is already present. 
> " /eal/heap_list"

My bad!

> > > --> /eal/element_list,0,1,15  
> > > {"/eal/element_list": {"Element_count": 52}}
> > >
> > > 5. /eal/element_info,<heap-id>,<memseg-list-id>,<memseg-id>,  \
> > >    <elem-start-id>,<elem-end-id>
> > > The command outputs element information like element start address,
> > > end address, to which memseg it belongs, element state, element size.
> > > User can give a range of elements to be printed.
> > > Example:  
> > > --> /eal/element_info,0,1,15,1,2  
> > > {"/eal/element_info": {"element.1": {"msl_id": 1,    \
> > > "ms_id": 15, "memseg_start_addr": "0xb20000000",     \
> > > "memseg_end_addr": "0xb40000000",                    \
> > > "element_start_addr": "0xb201fe680",                 \
> > > "element_end_addr": "0xb20bfe700",                   \
> > > "element_size": 10485888, "element_state": "Busy"},  \
> > > "element.2": {"msl_id": 1, "ms_id": 15,              \
> > > "memseg_start_addr": "0xb20000000",                  \
> > > "memseg_end_addr": "0xb40000000",                    \
> > > "element_start_addr": "0xb20bfe700",                 \
> > > "element_end_addr": "0xb215fe780", "element_size": 10485888, \
> > > "element_state": "Busy"}, "Element_count": 2}}  
> > 
> > How this request is going to be used?
> > Elements don't have permanent IDs like MSL/memseg index or heap ID.
> > Heap layout may change between /eal/element_list and this request.  
> 
> Idea here was to print information related to memory element. This information
> Can be printed for a single element or for a range of elements.

I understand what this request does, the question is: what info the user has
initially, what they want to learn, and whether the request helps them.
For example, if the user wants to understand
which elements hold the known hugepage from being freed,
then your request is good as it is.
On the other hand, if the user initially has an address from some debug print
and wants to know if it's free, and if not, what's there,
then my suggestion about query by address is more suitable.
Or maybe both are good to have eventually.
 
> > Maybe instead there should be a filter by address with maybe a context
> > parameter (like "grep -C")?  
> 
> You mean that the user shall be able to grep for a memory address to check
> which element it belongs to ? If my understanding is correct, can I implement
> it as new request post rc2 and keep this request as-is?

Yes, this is what I mean.
AFAIU, rc1 is API freeze, and telemetry is API, so the new request must wait.
If the current request helps solving actual issues, of course let's have it.