All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Wodkowski, PawelX" <pawelx.wodkowski@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH] vfio: allow to map other memory regions
Date: Wed, 28 Jun 2017 13:50:46 +0200	[thread overview]
Message-ID: <8830088.21c9ZRnMaC@xps> (raw)
In-Reply-To: <F6F2A6264E145F47A18AB6DF8E87425D52D87325@IRSMSX102.ger.corp.intel.com>

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 <pawelx.wodkowski@intel.com>
> > 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 <pawelx.wodkowski@intel.com>
> > > ---
> > >  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.

      reply	other threads:[~2017-06-28 11:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-17 14:44 [RFC][PATCH] vfio: allow to map other memory regions Pawel Wodkowski
2017-05-17 17:20 ` Stephen Hemminger
2017-05-18  9:06   ` Wodkowski, PawelX
2017-05-18 11:23 ` Burakov, Anatoly
2017-05-23 13:53 ` [PATCH v2] " Pawel Wodkowski
2017-05-23 13:59   ` [PATCH v3] " Pawel Wodkowski
2017-05-24 11:17     ` [PATCH] " Pawel Wodkowski
     [not found]       ` <1496663643-65002-1-git-send-email-pawelx.wodkowski@intel.com>
2017-06-05  8:16         ` Wodkowski, PawelX
2017-06-13  9:02       ` Burakov, Anatoly
2017-06-19 21:04       ` Thomas Monjalon
2017-06-28  9:54         ` Wodkowski, PawelX
2017-06-28 11:50           ` Thomas Monjalon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8830088.21c9ZRnMaC@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=pawelx.wodkowski@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.