From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: Huge pages to be allocated based on number of mbufs Date: Thu, 17 Mar 2016 17:25:30 +0000 Message-ID: <56EAE88A.5030004@linaro.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: Saurabh Mishra , users@dpdk.org, dev@dpdk.org Return-path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 3D2CD56A2 for ; Thu, 17 Mar 2016 18:25:15 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id l68so36022605wml.0 for ; Thu, 17 Mar 2016 10:25:15 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 14/03/16 17:54, Saurabh Mishra wrote: > Hi, > > We are planning to support virtio, vmxnet3, ixgbe, i40e, bxn2x and SR-IOV > on some of them with DPDK. > > We have seen that even if we give correct number of mbufs given the number > hugepages reserved, rte_eth_tx_queue_setup() may still fail with no enough > memory (I saw this on i40evf but worked on virtio and vmxnet3). > > We like to know what's the recommended way to determine how many hugepages > we should allocate given the number of mbufs such that queue setup APIs > also don't fail. I think you ran into a fragmentation problem. If you allocate the hugepages later on after startup, chances are they are fragmented in the memory. When you allocate a pool, DPDK needs a continuous area of memory on the hugepages. You should allocate them through the kernel boot params so they'll be as continuous as possible. > > Since we will be running on low-end systems too we need to be careful about > reserving hugepages. > > Thanks, > /Saurabh >