From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: [PATCH v3 0/4] Allow using external memory without malloc Date: Fri, 21 Dec 2018 09:17:18 +0000 Message-ID: References: <20181220081646.55593779@xeon-e3> <7324739.01YbsFNNIY@xps> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Stephen Hemminger , shahafs@mellanox.com, yskoh@mellanox.com, shreyansh.jain@nxp.com To: Thomas Monjalon Return-path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id C929C4CA9 for ; Fri, 21 Dec 2018 10:17:21 +0100 (CET) In-Reply-To: <7324739.01YbsFNNIY@xps> 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" On 20-Dec-18 5:18 PM, Thomas Monjalon wrote: > 20/12/2018 17:16, Stephen Hemminger: >> On Thu, 20 Dec 2018 15:32:37 +0000 >> Anatoly Burakov wrote: >> >>> 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 be suitable for certain other use >>> cases like manual memory management, etc. >>> >>> 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. >>> >>> 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, as well as >>> no mem event callbacks are triggered. >>> >>> 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 of >>> API is kept, and flexibility is also allowed. >>> >>> [1] https://mails.dpdk.org/archives/dev/2018-November/118175.html >> >> Where are the examples for this? Give a sample application maybe. >> >> Also there are no test cases. > > It looks to be a big task, but yes, would be nice to have test > of external memory allocation in DPDK unit tests. > I imagine if i submitted patches for this, since it's test code, it can go into rc1? Or is that considered a "feature"? I don't think it will be a lot of code, there are only 4 new API calls. Extending extmem autotest should do the trick. Adding a new testpmd mode is also possible but less trivial, and can be postponed to 19.05. -- Thanks, Anatoly