From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 8F83A2C13 for ; Wed, 28 Jun 2017 13:50:48 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1D0BA20BA2; Wed, 28 Jun 2017 07:50:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 28 Jun 2017 07:50:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=RTO4YpAzOuoQGip kq610Erq6FZs1ed5qJ+A4YA8SyXk=; b=WVZcBWmps67eS6/oX0F0B58YX/3F+86 n4wcNtn2MR+ignOqraNduR2hYtAPDxawJdyUnMgVDMnvppIqXjA35TJJbwEsuTOE gk9Ze3zfAfvVUPYUpl+JUYkdCD6DPAch51xrppBHvPk2+T5/pqj5VKNVfxcLz99B SP2bUD+Yc5A8= 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=RTO4YpAzOuoQGipkq610Erq6FZs1ed5qJ+A4YA8SyXk=; b=RymrZjxS tFRKv7WePob6fpdxBK0GQF7yXe/h06Lb+QJWx+LXyy9zcVSnIbDAd1WCQkmTUlUy oZ4SlXoj+bG9O5ePscn2RmqDxtoLr6YBwc5K1toqpF6klOr6ABajkluJbcRZ2BXT JKrykMhVCPgOYalo/D3WxDxatlR7FZVFgGa9Mg5lPxn4zY3yQvaQUYF5oJnE2a/W 1rBhT7kURZ6klfFIeuDh6Pz9YEfPC1BTJOcxw90pZUs8LMKmY1lSWHv7bEZ2yTKE avSDZNKVJ/39QXO6TIce3wrCfjGsZgSdyhdaT5pPI/P+NLB89ct06f/Lg5oFXkfY w0ZI61EoO8DrqA== X-ME-Sender: X-Sasl-enc: zf+wRizsAGtORyOmyOyMJm4myQRNgk5NG0025s8aThLB 1498650647 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C0516247A2; Wed, 28 Jun 2017 07:50:47 -0400 (EDT) From: Thomas Monjalon To: "Wodkowski, PawelX" Cc: dev@dpdk.org Date: Wed, 28 Jun 2017 13:50:46 +0200 Message-ID: <8830088.21c9ZRnMaC@xps> In-Reply-To: References: <1495547976-96270-1-git-send-email-pawelx.wodkowski@intel.com> <2829321.iV2IKkVC0J@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] vfio: allow to map other memory regions 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: Wed, 28 Jun 2017 11:50:48 -0000 28/06/2017 11:54, Wodkowski, PawelX: > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Monday, June 19, 2017 11:04 PM > > To: Wodkowski, PawelX > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] vfio: allow to map other memory regions > > > > Hi, > > Some comments below > > > > 24/05/2017 13:17, Pawel Wodkowski: > > > Currently it is not possible to use memory that is not owned by DPDK to > > > perform DMA. This scenarion might be used in vhost applications (like > > > SPDK) where guest send its own memory table. To fill this gap provide > > > API to allow registering arbitrary address in VFIO container. > > > > > > Signed-off-by: Pawel Wodkowski > > > --- > > > lib/librte_eal/linuxapp/eal/Makefile | 3 + > > > lib/librte_eal/linuxapp/eal/eal_vfio.c | 142 > > +++++++++++++++++++++--- > > > lib/librte_eal/linuxapp/eal/eal_vfio.h | 10 ++ > > > lib/librte_eal/linuxapp/eal/include/rte_iommu.h | 78 +++++++++++++ > > > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 8 ++ > > > 5 files changed, 224 insertions(+), 17 deletions(-) > > > create mode 100644 lib/librte_eal/linuxapp/eal/include/rte_iommu.h > > > > VFIO is not referenced in the doxygen of these functions. > > Could we use this API for something else than VFIO? > > This is for any IOMMU hw/module/driver used in host which require special > care about memory regions used for DMA. It is not restricted to VFIO even though > only VFIO is implemented. > > > > > Any API should be declared in common directory, even if it is not > > implemented for FreeBSD (returning -ENOTSUP). > > I think those function should be NOP for FreeBSD (like RTE_VFIO_NOIOMMU do) > or be conditionally compiled/included (like it is now). I decide to take second way. > Do you think that I should move rte_iommu.h to common directory and use #ifdef > there? No #ifdef please. You must define new functions in a common header and implement it for Linux and BSD. The BSD function can be return an error.