From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id 7883A5A30 for ; Wed, 13 May 2015 13:08:48 +0200 (CEST) Received: by wicnf17 with SMTP id nf17so51027549wic.1 for ; Wed, 13 May 2015 04:08:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UtdgVC/IRX3uXyW2DO8hCNgK+dSzyxYH4gXQ9RDzuAU=; b=Ejm4o4hJnbspNttePVXdVxiGyJHimBW/ASLOBUsxNniT5m+E3G58I6whEBHM/k95D7 +Q9RvIECqXBv5fZh38ayuQhltR1uVcx8NxbFR6e+FOzq83AOE0lUksKcIz24VwBwpo7e +LAXWu0AxPKR9qW6ETUzkLgxDoUQrMUvRrqslZOttrZFbXdr6vzacW+U8blL4vDK2Hw+ ypVQVcTKYFlscO6vIrFC8M2L8p7FgE6KPH6xszO5zrS5EEgN82u3QcieCgE+ESAxGX+j 3ym+jV0zsAHVHCe0n+xxUj+F67XmtVGjOOWcl45L5gTEmgogkTyMG53HB0XV0s02/6o/ WJZQ== X-Gm-Message-State: ALoCoQlvXQNADNZcOdDWjXrDQ7PlKtbn+COUHHKRLsYKVbWXAFX8eWrGVoPqF3vZw5lLw7f57s5n X-Received: by 10.194.159.99 with SMTP id xb3mr39079500wjb.57.1431515328334; Wed, 13 May 2015 04:08:48 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id l6sm32372422wjz.4.2015.05.13.04.08.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 04:08:47 -0700 (PDT) Message-ID: <555330BB.4070908@6wind.com> Date: Wed, 13 May 2015 13:08:43 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: "Gonzalez Monroy, Sergio" References: <554A3D0A.6070605@intel.com> <555212B7.6030604@6wind.com> <55532400.2020503@intel.com> In-Reply-To: <55532400.2020503@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Regarding rte_memzone_reserve with len =0 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: Wed, 13 May 2015 11:08:48 -0000 On 05/13/2015 12:14 PM, Gonzalez Monroy, Sergio wrote: > On 12/05/2015 15:48, Olivier MATZ wrote: >> Hi Sergio, >> >> On 05/06/2015 06:10 PM, Gonzalez Monroy, Sergio wrote: >>> Hi, >>> >>> I was wondering about the use case of rte_memzone_reserve_xxxx APIs with >>> len=0. >>> >>> From the docs (http://dpdk.org/doc/api/rte__memzone_8h.html): >>> len The size of the memory to be reserved. If it is 0, the >>> biggest contiguous zone will be reserved. >>> >>> What are the use cases? >>> When would you want a memzone of undetermined size? >>> >>> Any thoughts appreciated. >> >> As the application does not have access to the lengths of memory >> segments, probably the initial idea is when an application wants >> to allocate more memory that the biggest segment. >> >> Example, the application wants to allocate 1G (even fragmented): >> >> - the easy case is when it can be done in one call to >> rte_memzone_reserve(1G) >> >> - else, the application can iterate like in this sample: >> >> remain = 1 * 1024 * 1024 * 1024; >> while (remain > 0) { >> mz = rte_memzone_reserve(remain); >> if (mz != NULL) >> return 0; >> mz = rte_memzone_reserve(remain); > You meant rte_memzone_reserve(0) here, right? yes, sorry for the typo