From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.oneaccess-net.com (mail2.belgium.oneaccess-net.com [91.183.184.101]) by dpdk.org (Postfix) with ESMTP id 6075A2BFF for ; Tue, 4 Oct 2016 10:00:26 +0200 (CEST) Received: from localhost.oneaccess.intra (10.0.21.133) by oab1mx2.oneaccess.intra (10.0.24.95) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 4 Oct 2016 10:00:26 +0200 From: Renata Saiakhova To: Message-ID: <57F36199.5020100@oneaccess-net.com> Date: Tue, 4 Oct 2016 10:00:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.0.21.133] Subject: [dpdk-users] rte_segments: hugepages are not in contiguous memory X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 08:00:26 -0000 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