[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