From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id A564C1BDC0 for ; Thu, 20 Dec 2018 18:18:08 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3AEEE22242; Thu, 20 Dec 2018 12:18:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 20 Dec 2018 12:18:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=teKMjEHYRWErh2Ax/I48QElFtoJWk/IKq3v0i0P36Ig=; b=B5eLlhg7eUXl AMt37YAVl0puCQ4K0N3sWOXgz5x8Vof/lMn9sVBY35EQs7mUllpEcdMg8sNLXcX4 pBIrTedbMJ0qji0mZ4Q+dPvx3BBKcgWi6UhFBODhJN5lwxDCFd/PYo24uRa8A6zi KExULf7ZJTbEh9K8EAvX17wOo0tOOzo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=teKMjEHYRWErh2Ax/I48QElFtoJWk/IKq3v0i0P36 Ig=; b=Sur6/qEL1ag4avoL3PmEqjvFQgnTspDecOEJzvLhdC9jr30PN512VZY38 4wdUMzAdQkZuI0vJssnjTxKnBOZHamuTbojbX7VMXbP5Vg8C2GTZT1C3msgTt7D/ Grxu+Rw2Mu72fv/npp27eSegQvzpD5whl4afPZbWIdAxcWVbhJBmuvtRlEoH0PTp UpHlLTKPWkSq09qmj59XfK2xviIaGsqwh5eeRHrxMrzGUx4u35jiCoJ7SyCfUiHw i+0K4dzsz/NmHPpyyMfxedTc1ltsj8qLTPJvR5N8/AM/d5RmqOyzNEDIuh7UF53W +AF8ukxWQkEhW5UCndQTfYN0nXWQw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejfedguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkf gjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhn uceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuffhomhgrihhnpeguphgukh drohhrghenucfkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhl fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C5EEE446A; Thu, 20 Dec 2018 12:18:06 -0500 (EST) From: Thomas Monjalon To: Anatoly Burakov Cc: dev@dpdk.org, Stephen Hemminger , shahafs@mellanox.com, yskoh@mellanox.com, shreyansh.jain@nxp.com Date: Thu, 20 Dec 2018 18:18:05 +0100 Message-ID: <7324739.01YbsFNNIY@xps> In-Reply-To: <20181220081646.55593779@xeon-e3> References: <20181220081646.55593779@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Thu, 20 Dec 2018 17:18:09 -0000 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.