It could also be that this is the function that is the most time consuming:malloc_heap_alloc_on_heap_id() still looking, I suspect others have encountered such an issue and know what the problem is ... On Wednesday, April 22, 2020, 04:45:11 PM PDT, amit sehas <cu...@yahoo.com> wrote: I switched from utilizing dpdk 16.11.1 to dpdk 18.11.6, in the process I started utilizing --single-file-segments,previously I was utilizing a patch for the same functionality on dpdk-16.11.1. And while linking I somehowneed to link in -lnuma now which I previously did not need to. I don't know what dependencies have beenintroduced by dpdk-18.11.6 but I can no longer build my executables without linking in numa. That is the only notable change I made. And nothing else has changed, huge pages, tlbs etc are all the same. yet the performance of rte_pktmbuf_pool_create() has completely tanked, it has become much much slower.I am quite new to dpdk and am not sure what is going on … so I went in with a debugger and this is whati find: this function call is taking up all the time: rte_mempool_populate_default() which in turn invokes the following which is taking all the time: rte_memzone_reserve_aligned() which in turn invokes the following which is taking all the time:memzone_reserve_aligned_thread_unsafe() which in turn invokes the following which is taking all the time: malloc_heap_alloc() which in turn invokes the following which is taking all the time: malloc_get_numa_socket()
My guess is that somehow numa has started interfering with the performance, but i am not quite sure what to do to fix it... any help is greatly appreciated, i suspect someone familiar with the above should quickly identify the issue and its remedy... regards
