[dpdk-users] rte_segments: hugepages are not in contiguous memory

Renata Saiakhova Renata.Saiakhova at oneaccess-net.com
Tue Oct 4 10:00:25 CEST 2016


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



More information about the users mailing list