From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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=iFp+GnGRvHe9THpFP4ABrDfwIDbQGcG24GS1d4SNRj6VcmV9yTpiWQrG3UgQMBzcik 1xi85FsI1XYzUnTf9fnoPuHscCusYuPxUn0k8xhUEELqSVFc7jeCpIG4rk9SEOZsDwiz 2jXlGQ5URK944BifkgT0mdOgOBSJsrW/FmaQXoNmtOV7+l6rlLNoEvgn2hvkI39AorhG 1tc2O+wLPfYXJ+m9y5U6YNGqm+B4jVqVw9KHk1Rj6pq5FcAst68yyVZ0VesT55mJzY4C k7PyOGKmZis5PRs9oQc4b9vnIxPD0e88c90zoFdCyL6gVWPhMbPKLvl8bLS38c2NZldg 1Fmg== X-Gm-Message-State: AD7BkJIO5lGg2LlYwXH864C5xspMq+C6VOYJtavLimy+XUTor1Dox3NvlbYHhldn5fHTaAuo 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 Subject: Re: [dpdk-dev] Huge pages to be allocated based on number of mbufs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK 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 >