How to track memory allocation via DPDK API rte_malloc? - dpdk

Question

Based on DPDK API documentation rte_malloc_dump_stats is said to Dump for the specified type to a file. But neither custom application or app/test/test_malloc.c shares the desired result.
Expectation: for DPDK API rte_malloc, rte_calloc, and rte_zmalloc is created with const char *type. the stats for specific const char *type can be queried with rte_malloc_dump_stats
Current result: DPDK API rte_malloc_dump_stats gives overall heap usage, without any information about which "type" uses how much.
Question: Is there any other API available in DPDK to track the huge page malloc usage? Any DPDK patch would be useful?
Sample code flow:
/* with huge page */
rte_eal_init
/* create memory location for various object type */
rte_malloc ("objecttype-1")
rte_malloc ("objecttype-2")
rte_malloc ("objecttype-3")
rte_malloc ("objecttype-4")
/* dump stats for object type - 1 */
rte_malloc_dump_stats ("objecttype-1")
My application calls rte_calloc, which calls few other internal subroutines and finally calls heap_alloc (in which "type" seems to be unsed).
heap_alloc(struct malloc_heap *heap, const char *type __rte_unused, size_t size, unsigned int flags, size_t align, size_t bound, bool contig). Heap alloc currently seems to ignore the "type" argument. How to track the heap memory usage?

Answer 1

The observation is correct, currently DPDK API rte_malloc, rte_zalloc, rte_calloc discards the name field which is represented by first argument as const char *type. Hence dump or query with DPDK API rte_malloc_dump_stats does not return for specific const char *type.
There are a couple of workaround to this problem (without modifying the DPDK library), such as
rte_memzone_reserve creates a named area (which can be the desired type) as a repalcement.
rte_mempool_create_empty to create a named empty mempool.
both approaches have its disadvantages
memzone: is normally targeted for larger areas and called once, hence frequent calls to memzone_reserve for the small objects will have a performance impact. One has to also use rte_memzone_walk to iterate through the desired const char *type to get the details too.
empty_mempool: expects all objects put into are of the same size, hence it is useful in places like creating a pool of reusable counters, or lists. But using rte_mempool_lookup has an easier way to access the pool for details like the number of elements, size and cached elements per core etc.
There is a much easier alternative by simply creating Create a container to hold malloc|calloc|zalloc name, pointer and size using fb_arry. on every successful allocation fetch an element holder from fb_array and update the details. major advantage of this approach is fb_arry can be extended on huge page via rte_memzone_reserve, which makes monitoring of const char *type with almost no modification.
Code Snippet:
struct rte_memzone *mptr = NULL;
struct elements {
char name[256];
void *ptr;
};
/* right after rte_eal_init */
mptr = rte_memzone_reserve_aligned("MALLOC_REGIONS",
sizeof(struct rte_fbarray), SOCKET_ID_ANY,
RTE_MEMZONE_2MB, 8);
/* create a wrapper or MACRO to insert details of each alloc with type field */
do
{
ptr = rte_malloc(NULL, size_dataoibject, 0);
if (ptr == NULL)
return NULL;
int index = rte_fbarray_find_next_free((struct rte_fbarray *)mptr->addr, 0);
if (index < 0) {
printf("fail in rte_fbarray_find_next_free %d", index);
rte_free(ptr);
return NULL;
}
return ptr;
} while(0);
/* in the data processing thread, invoke the MACRO/function*/
references:
DPDK debug guide
malloc monitor