From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shahaf Shuler Subject: Re: [PATCH 0/4] Allow using external memory without malloc Date: Sun, 2 Dec 2018 05:48:37 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Yongseok Koh , Thomas Monjalon , "shreyansh.jain@nxp.com" To: Anatoly Burakov , "dev@dpdk.org" Return-path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00056.outbound.protection.outlook.com [40.107.0.56]) by dpdk.org (Postfix) with ESMTP id C526C1B4F7 for ; Sun, 2 Dec 2018 06:48:38 +0100 (CET) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Anatoly,=20 Thursday, November 29, 2018 3:49 PM, Anatoly Burakov: > Subject: [PATCH 0/4] Allow using external memory without malloc >=20 > Currently, the only way to use externally allocated memory is through > rte_malloc API's. While this is fine for a lot of use cases, it may not b= e suitable > for certain other use cases like manual memory management, etc. >=20 > This patchset adds another API to register memory segments with DPDK (so > that API's like ``rte_mem_virt2memseg`` could be relied on by PMD's and > such), but not create a malloc heap out of them. >=20 > Aside from the obvious (not adding memory to a heap), the other major > difference between this API and the ``rte_malloc_heap_*`` external memory > functions is the fact that no DMA mapping is performed automatically. >=20 > This really draws a line in the sand, and there are now two ways of doing > things - do everything automatically (using the ``rte_malloc_heap_*`` API= 's), > or do everything manually (``rte_extmem_*`` and future DMA mapping API > [1] that would replace ``rte_vfio_dma_map``). This way, the consistency o= f > API is kept, and flexibility is also allowed. >=20 As you know I like the idea. One question though, do you see a use case for application to have external= ly allocated memory which needs to be registered to the DPDK subsystem howe= ver not being used for DMA? My only guess would be so helper libraries which requires the memory alloca= tion from user (however it doesn't seems like a good API).=20 If no use case, maybe it is better to merge between the two (rte_extmem_* a= nd rte_dma_map) to have a single call for app to register and DMA map the m= emory. The rte_mem_virt2memseg is not something application needs to unders= tand, it is used internally by PMDs or other libs.=20 > [1] > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fma > ils.dpdk.org%2Farchives%2Fdev%2F2018- > November%2F118175.html&data=3D02%7C01%7Cshahafs%40mellanox.co > m%7C007a9234feaf42c82f6508d656015eb1%7Ca652971c7d2e4d9ba6a4d1492 > 56f461b%7C0%7C0%7C636790961244424277&sdata=3DYqwcPEEhJM3I7Toe > Ne%2BGcbeo%2FmPbYEnNFckoA7ES2Hg%3D&reserved=3D0 >=20 > Note: at the time of this writing, there's no release notes > template, so no release notes updates in this patchset. > They will be added in later revisions. >=20 > Anatoly Burakov (4): > malloc: separate creating memseg list and malloc heap > malloc: separate destroying memseg list and heap data > mem: allow registering external memory areas > mem: allow usage of non-heap external memory in multiprocess >=20 > .../prog_guide/env_abstraction_layer.rst | 63 +++++++-- > lib/librte_eal/common/eal_common_memory.c | 116 > +++++++++++++++++ > lib/librte_eal/common/include/rte_memory.h | 122 > ++++++++++++++++++ > lib/librte_eal/common/malloc_heap.c | 104 +++++++++++---- > lib/librte_eal/common/malloc_heap.h | 15 ++- > lib/librte_eal/common/rte_malloc.c | 115 +++++++---------- > lib/librte_eal/rte_eal_version.map | 4 + > 7 files changed, 434 insertions(+), 105 deletions(-) >=20 > -- > 2.17.1