From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2018 01:17:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,380,1539673200"; d="scan'208";a="131831355" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.252.9.59]) ([10.252.9.59]) by fmsmga001.fm.intel.com with ESMTP; 21 Dec 2018 01:17:19 -0800 To: Thomas Monjalon Cc: dev@dpdk.org, Stephen Hemminger , shahafs@mellanox.com, yskoh@mellanox.com, shreyansh.jain@nxp.com References: <20181220081646.55593779@xeon-e3> <7324739.01YbsFNNIY@xps> From: "Burakov, Anatoly" Message-ID: Date: Fri, 21 Dec 2018 09:17:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <7324739.01YbsFNNIY@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 0/4] Allow using external memory without malloc X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 09:17:22 -0000 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