2022-09-23 11:20 (UTC+0000), Umakiran Godavarthi (ugodavar): > [Uma] : Yes we are unmapping the entire range hoping all are free inside > DPDK and DPDK heaps never use these pages. > > Suppose we have 400 pages total free_hp, we want only 252 pages , so we > reduce nr_pages to 252. > > So we assume 253 to 400 inside DPDK are free as we nr_pages are made by my > application as 252. > > ms_idx = rte_fbarray_find_next_n_free(arr, 0, 2); -> 253 comes > ms_check_idx = rte_fbarray_find_next_n_free(arr, 0, > RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va, msl->len), addr)/msl->page_sz); -> 253 > comes (should be same as above) > ms_next_idx = rte_fbarray_find_next_used(arr, ms_idx); -> This comes -1 as > NO USED page is there (<0) > > Hence we call unmap like -> munmap(addr, > RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va, msl->len), addr)); > > Please let us know how to check in DPDK free heaps or FBARRAY that these > pages we are freeing are really safe ? (253 to 400 unwanted pages by our > application, other than above 3 checks) > > If it’s not safe to free, how to inform DPDK to free those pages in FBARRAY > and also clean up its heap list so that it never crashes !!
There still DPDK malloc internal structures that you cannot adjust. I suggest going another way: Instead of letting DPDK allocate all hugepages and unmapping some, allow DPDK to allocate an absolute minimum (1 x 2MB page?) and add all the rest you need via rte_extmem_*() API. Why do you need legacy mode in the first place? Looks like you're painfully trying to achieve the same result that dynamic mode would give you automatically.
