Hi all, I'm using dpdk 16.04 (I tried 16.07 with the same results) and linux kernel 4.4.20 in a virtual machine (I'm using libvirt framework). I pass a parameter in kernel command line to allocate 512 hugepages of 2 MB at boot time. They are successfully allocated. When an application with dpdk starts it calls rte_pktmbuf_pool_create() which in turns requests internally 649363712 bytes. Those bytes should be allocated from one of rte_memseg. rte_memsegs describes contiguous portions of memory (both physical and virtual) built on hugepages. This allocation fails, because there are no rte_memsegs of this size (or bigger). Further debugging shows that hugepages are allocated in non-contiguous physical memory and therefore rte_memsegs are built respecting gaps in physical memory. Below are the sizes of segments built on hugepages (in bytes) 2097152 6291456 2097152 524288000 2097152 532676608 2097152 2097152 So there are 5 segments which includes only one hugepage! This behavior is completely different to what I observe with linux kernel 3.8 (used with the same application with dpdk) - where all hugepages are allocated in contiguous memory. Does anyone experience the same issue? Could it be some kernel option which can do the magic? If not, and kernel can allocated hugepages in non-contiguous memory how dpdk is going to resolve it?
Thanks in advance, Renata
