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

[Amit Prakash Shukla <amitprakashs@marvell.com>]

Hi Dmitry,

Sure, will implement 2 new request (1. Msl properties, 2. Address lookup) in a separate patch. 
I will work on other review suggestions as part of v6.

Thanks,
Amit Shukla

> -----Original Message-----
> From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> Sent: Saturday, October 22, 2022 1:38 AM
> To: Amit Prakash Shukla <amitprakashs@marvell.com>
> Cc: Anatoly Burakov <anatoly.burakov@intel.com>; dev@dpdk.org; Jerin
> Jacob Kollanukkaran <jerinj@marvell.com>; david.marchand@redhat.com;
> bruce.richardson@intel.com; ciara.power@intel.com
> Subject: Re: [EXT] Re: [PATCH v5 1/2] mem: telemetry support for memseg
> and element information
> 
> 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.