From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: memory allocation requirements
Date: Wed, 13 Apr 2016 18:03:25 +0200
Message-ID: <1500486.8lzTDt5Q91@xps13>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: sergio.gonzalez.monroy@intel.com
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44])
 by dpdk.org (Postfix) with ESMTP id 05DA537B4
 for <dev@dpdk.org>; Wed, 13 Apr 2016 18:03:28 +0200 (CEST)
Received: by mail-wm0-f44.google.com with SMTP id u206so86731267wme.1
 for <dev@dpdk.org>; Wed, 13 Apr 2016 09:03:28 -0700 (PDT)
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

After looking at the patches for container support, it appears that
some changes are needed in the memory management:
http://thread.gmane.org/gmane.comp.networking.dpdk.devel/32786/focus=32788

I think it is time to collect what are the needs and expectations of
the DPDK memory allocator. The goal is to satisfy every needs while
cleaning the API.
Here is a first try to start the discussion.

The memory allocator has 2 classes of API in DPDK.
First the user/application allows or requires DPDK to take over some
memory resources of the system. The characteristics can be:
	- numa node
	- page size
	- swappable or not
	- contiguous (cannot be guaranteed) or not
	- physical address (as root only)
Then the drivers or other libraries use the memory through
	- rte_malloc
	- rte_memzone
	- rte_mempool
I think we can integrate the characteristics of the requested memory
in rte_malloc. Then rte_memzone would be only a named rte_malloc.
The rte_mempool still focus on collection of objects with cache.

If a rework happens, maybe that the build options CONFIG_RTE_LIBRTE_IVSHMEM
and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS can be removed.
The Xen support should also be better integrated.

Currently, the first class of API is directly implemented as command line
parameters. Please let's think of C functions first.
The EAL parameters should simply wrap some API functions and let the
applications tune the memory initialization with a well documented API.

Probably that I forget some needs, e.g. for the secondary processes.
Please comment.