DPDK usage discussions
 help / color / mirror / Atom feed
From: Renata Saiakhova <Renata.Saiakhova@oneaccess-net.com>
To: <users@dpdk.org>
Subject: [dpdk-users] rte_segments: hugepages are not in contiguous memory
Date: Tue, 4 Oct 2016 10:00:25 +0200	[thread overview]
Message-ID: <57F36199.5020100@oneaccess-net.com> (raw)

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

             reply	other threads:[~2016-10-04  8:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04  8:00 Renata Saiakhova [this message]
2016-10-04  8:27 ` Sergio Gonzalez Monroy
2016-10-04  9:38   ` Renata Saiakhova
2016-10-04 10:13     ` Andriy Berestovskyy
2016-10-04 10:48       ` Renata Saiakhova
2016-10-04 11:27         ` Andriy Berestovskyy
2016-10-04 12:02           ` tom.barbette
2016-10-04 14:09             ` Sergio Gonzalez Monroy
2016-10-06 11:02               ` tom.barbette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57F36199.5020100@oneaccess-net.com \
    --to=renata.saiakhova@oneaccess-net.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).