> > > Not sure if they are in DPDK scope, apart from rte_mem_lock, which > > generalizes rte_mem_lock_page already in rte_memory.h. What may be > typical > > use cases for data-plane apps? I can see testpmd using mmap for > allocating > > external memory (because of possible use of hugepages), does it need > these > > functions exposed? > > There is a chance the application needs such functions > for another part of its dataplane.
Such reasoning can justify any API. DPDK needs compatibility layers, but collecting and providing them is not the goal of the kit. I can only think of using mmap in data plane as a high-performance IPC with non-DPDK management app. Please add the @internal tag in doxygen to make the status clear. > OK. > > > > +#include <rte_eal_memory.h> > > > > > > I think we should find a better file name for these wrappers. > > > "EAL memory" means DPDK memory allocator in my mind. > > > We need a file name which is about OS-independent wrappers, > > > or libc wrappers. > > > What about rte_libc_mem.h? rte_mem_os.h? something else? > > > > See above, but anyway, "libc" is non-generic. > > Why libc is not generic? > It means nothing on Windows. Also, mmap has little to do with libc. Which file name can it be? > Your rte_mem_os.h sounds good, except internal header better be rte_eal_mem_os.h. Alternative: rte_eal_paging.h. >
