From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 39BB0567F for ; Thu, 17 Mar 2016 18:25:15 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id l68so36022555wml.0 for ; Thu, 17 Mar 2016 10:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=xlkeK7aiRmvL7GQEBBu0T1VPJ1xWXQT83sGO5h6X7nA=; b=KO+SxfLrBDZgAeMYx4RcjSNdhrPApw8Ga/vbGVkTKRInykNzlkilbin5IjLJ2UTqiO OWyUlsBGBcKspfpG2zUU/qOBSHIaIgcBhWEmt/ZMwiA2B8fKgTVfJrAbnXs0dIv5HQrB z8LBIceVbKcWP1chGOPS7n/E8Eco9uyHNM8A8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xlkeK7aiRmvL7GQEBBu0T1VPJ1xWXQT83sGO5h6X7nA=; b=jqEM/RwEhxZljmcrrglKZB+Usbl+zwTbeV+kPhr8v6rjCJp600V/K29/gScu3U9+4/ haIeYAFcrhip0BTFz05sV1OP1A1hDQ01xPIuPso7v0telUnt36udPpWcDLQOdxAzQifH W0DCw9ksHR4o4KC7ki7b6k//+hVdCUEvTfeMIvFLB4pH35Canim0GxEJ/CkxaZRwZlgJ RntJSNnLRDEiG0Xex/TPrwuWg/JzBudgJCWz+8/G5YF0MKnOexBptMuC+u8RO63mX59m OVht20hLkGc/09wvIYnW1eR0HpvNbGM5uVzGh2ZvHQKPfQQ3/sCQX17GFiHMqUw90G/I VITA== X-Gm-Message-State: AD7BkJJ1ekZYSqQsONAyf4yFkppcIhovYjbRNtnz9FTL5qXSYCv+YDolfUPqQhFgWmP2YPAK X-Received: by 10.194.189.71 with SMTP id gg7mr11330797wjc.127.1458235515027; Thu, 17 Mar 2016 10:25:15 -0700 (PDT) Received: from [172.18.45.108] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id h1sm9066419wme.8.2016.03.17.10.25.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 10:25:14 -0700 (PDT) To: Saurabh Mishra , users@dpdk.org, dev@dpdk.org References: From: Zoltan Kiss Message-ID: <56EAE88A.5030004@linaro.org> Date: Thu, 17 Mar 2016 17:25:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 17 Mar 2016 21:19:36 +0100 Subject: Re: [dpdk-users] [dpdk-dev] Huge pages to be allocated based on number of mbufs 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: Thu, 17 Mar 2016 17:25:15 -0000 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 >