From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 5A3671BB9F for ; Wed, 11 Apr 2018 16:35:42 +0200 (CEST) Received: from lfbn-lil-1-700-92.w81-254.abo.wanadoo.fr ([81.254.37.92] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f6GqY-0003ZW-4j; Wed, 11 Apr 2018 16:35:39 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Wed, 11 Apr 2018 16:35:34 +0200 Date: Wed, 11 Apr 2018 16:35:34 +0200 From: Olivier Matz To: Anatoly Burakov Cc: dev@dpdk.org, keith.wiles@intel.com, jianfeng.tan@intel.com, andras.kovacs@ericsson.com, laszlo.vadkeri@ericsson.com, benjamin.walker@intel.com, bruce.richardson@intel.com, thomas@monjalon.net, konstantin.ananyev@intel.com, kuralamudhan.ramakrishnan@intel.com, louise.m.daly@intel.com, nelio.laranjeiro@6wind.com, yskoh@mellanox.com, pepperjo@japf.ch, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, gowrishankar.m@linux.vnet.ibm.com Message-ID: <20180411143534.eiwrqjltjln25q4d@platinum> References: <17e7d16a54e2d3383a3857733589b91e2c691f66.1523448978.git.anatoly.burakov@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17e7d16a54e2d3383a3857733589b91e2c691f66.1523448978.git.anatoly.burakov@intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v6 24/70] mempool: add support for the new allocation methods X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 14:35:42 -0000 On Wed, Apr 11, 2018 at 01:29:59PM +0100, Anatoly Burakov wrote: > If a user has specified that the zone should have contiguous memory, > use the new _contig allocation API's instead of normal ones. > Otherwise, account for the fact that unless we're in IOVA_AS_VA > mode, we cannot guarantee that the pages would be physically > contiguous, so we calculate the memzone size and alignments as if > we were getting the smallest page size available. > > However, for the non-IOVA contiguous case, existing mempool size > calculation function doesn't give us expected results, because it > will return memzone sizes aligned to page size (e.g. a 1MB mempool > may use an entire 1GB page), therefore in cases where we weren't > specifically asked to reserve non-contiguous memory, first try > reserving a memzone as IOVA-contiguous, and if that fails, then > try reserving with page-aligned size/alignment. > > Signed-off-by: Anatoly Burakov > Tested-by: Santosh Shukla > Tested-by: Hemant Agrawal > Tested-by: Gowrishankar Muthukrishnan Acked-by: Olivier Matz