From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 9253C1BB1C for ; Wed, 11 Apr 2018 16:43:19 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id C252480076; Wed, 11 Apr 2018 14:43:17 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 11 Apr 2018 15:43:06 +0100 To: Anatoly Burakov , CC: Olivier Matz , , , , , , , , , , , , , , , , , References: <17e7d16a54e2d3383a3857733589b91e2c691f66.1523448978.git.anatoly.burakov@intel.com> From: Andrew Rybchenko Message-ID: Date: Wed, 11 Apr 2018 17:43:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <17e7d16a54e2d3383a3857733589b91e2c691f66.1523448978.git.anatoly.burakov@intel.com> Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23776.003 X-TM-AS-Result: No--19.017900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1523457798-KcGK5syNyhAc Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:43:20 -0000 On 04/11/2018 03:29 PM, 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. Just one minor nit.. As I understand _contig above is an artefact of the previous approach with dedicated function for contiguous allocation. If so, description should be updated to avoid confusion. > 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 > --- > lib/librte_mempool/rte_mempool.c | 148 +++++++++++++++++++++++++++++++++------ > 1 file changed, 127 insertions(+), 21 deletions(-)