From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44])
 by dpdk.org (Postfix) with ESMTP id 843955A35
 for <dev@dpdk.org>; Tue, 12 May 2015 16:48:27 +0200 (CEST)
Received: by wggj6 with SMTP id j6so12736887wgg.3
 for <dev@dpdk.org>; Tue, 12 May 2015 07:48:27 -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
 :subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=fAKv19RHgClHJbPU/ALbiXTuve5ud8Jew86Anig+yCE=;
 b=QUR8RYvEy8vSujf91y8uYAdKdkKDTmJCXzw5fxX6Y3vDbM3M2x3dkUQIGedVyRwh+o
 /BqN9cjb8vtgsT6mvgk74ATkFy8lsf3GiYMLY/8OyIK2gWqG5cKUmpTvJ9x2uJTT22MK
 Kovr03xQNTXyCEOQwmJ4L5W/NyotXdZiGMl3DTPCC20E9B/YR9CxXtp+NBvyB4/ceUvU
 5gb7l2N/h2MUE+xmKAkxcDr9PJQixmSQnzbrRj8669eFywaffYn5rOuziOAhwDcP/KPy
 eydRfXLLWFpTQWv/lb/73q4ikAKyqEh4wqPebMmEJlnIzVz4/Y45l/QKzHfsUtJ9/wIA
 iA0g==
X-Gm-Message-State: ALoCoQn8dXUd9ukJi/DWIlQeTKWyl8AzvuWTLtBRCUwMQEpI+P4XBFwNigcQ3FvlLXQUypwo5DF0
X-Received: by 10.180.74.238 with SMTP id x14mr31198002wiv.81.1431442107360;
 Tue, 12 May 2015 07:48:27 -0700 (PDT)
Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237])
 by mx.google.com with ESMTPSA id dj7sm28106016wjb.3.2015.05.12.07.48.25
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 12 May 2015 07:48:26 -0700 (PDT)
Message-ID: <555212B7.6030604@6wind.com>
Date: Tue, 12 May 2015 16:48:23 +0200
From: Olivier MATZ <olivier.matz@6wind.com>
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" <sergio.gonzalez.monroy@intel.com>, 
 "dev@dpdk.org" <dev@dpdk.org>
References: <554A3D0A.6070605@intel.com>
In-Reply-To: <554A3D0A.6070605@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 14:48:27 -0000

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);
          if (mz == NULL)
             return -1;
          remain -= mz->len;
      }

Regards,
Olivier