linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Kenneth Lee <liguozhu@hisilicon.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Kenneth Lee <nek.in.cn@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	Joerg Roedel <joro@8bytes.org>, Hao Fang <fanghao11@huawei.com>,
	Zhou Wang <wangzhou1@hisilicon.com>,
	Zaibo Xu <xuzaibo@huawei.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org,
	kvm@vger.kernel.org, linux-accelerators@lists.ozlabs.org,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Sanjay Kumar <sanjay.k.kumar@intel.com>,
	linuxarm@huawei.com
Subject: Re: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive
Date: Thu, 6 Sep 2018 09:31:33 -0400	[thread overview]
Message-ID: <20180906133133.GA3830@redhat.com> (raw)
In-Reply-To: <20180906094532.GG230707@Turing-Arch-b>

On Thu, Sep 06, 2018 at 05:45:32PM +0800, Kenneth Lee wrote:
> On Tue, Sep 04, 2018 at 10:15:09AM -0600, Alex Williamson wrote:
> > Date: Tue, 4 Sep 2018 10:15:09 -0600
> > From: Alex Williamson <alex.williamson@redhat.com>
> > To: Jerome Glisse <jglisse@redhat.com>
> > CC: Kenneth Lee <nek.in.cn@gmail.com>, Jonathan Corbet <corbet@lwn.net>,
> >  Herbert Xu <herbert@gondor.apana.org.au>, "David S . Miller"
> >  <davem@davemloft.net>, Joerg Roedel <joro@8bytes.org>, Kenneth Lee
> >  <liguozhu@hisilicon.com>, Hao Fang <fanghao11@huawei.com>, Zhou Wang
> >  <wangzhou1@hisilicon.com>, Zaibo Xu <xuzaibo@huawei.com>, Philippe
> >  Ombredanne <pombredanne@nexb.com>, Greg Kroah-Hartman
> >  <gregkh@linuxfoundation.org>, Thomas Gleixner <tglx@linutronix.de>,
> >  linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
> >  linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org,
> >  kvm@vger.kernel.org, linux-accelerators@lists.ozlabs.org, Lu Baolu
> >  <baolu.lu@linux.intel.com>, Sanjay Kumar <sanjay.k.kumar@intel.com>,
> >  linuxarm@huawei.com
> > Subject: Re: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive
> > Message-ID: <20180904101509.62314b67@t450s.home>
> > 
> > On Tue, 4 Sep 2018 11:00:19 -0400
> > Jerome Glisse <jglisse@redhat.com> wrote:
> > 
> > > On Mon, Sep 03, 2018 at 08:51:57AM +0800, Kenneth Lee wrote:
> > > > From: Kenneth Lee <liguozhu@hisilicon.com>
> > > > 
> > > > WarpDrive is an accelerator framework to expose the hardware capabilities
> > > > directly to the user space. It makes use of the exist vfio and vfio-mdev
> > > > facilities. So the user application can send request and DMA to the
> > > > hardware without interaction with the kernel. This removes the latency
> > > > of syscall.
> > > > 
> > > > WarpDrive is the name for the whole framework. The component in kernel
> > > > is called SDMDEV, Share Domain Mediated Device. Driver driver exposes its
> > > > hardware resource by registering to SDMDEV as a VFIO-Mdev. So the user
> > > > library of WarpDrive can access it via VFIO interface.
> > > > 
> > > > The patchset contains document for the detail. Please refer to it for more
> > > > information.
> > > > 
> > > > This patchset is intended to be used with Jean Philippe Brucker's SVA
> > > > patch [1], which enables not only IO side page fault, but also PASID
> > > > support to IOMMU and VFIO.
> > > > 
> > > > With these features, WarpDrive can support non-pinned memory and
> > > > multi-process in the same accelerator device.  We tested it in our SoC
> > > > integrated Accelerator (board ID: D06, Chip ID: HIP08). A reference work
> > > > tree can be found here: [2].
> > > > 
> > > > But it is not mandatory. This patchset is tested in the latest mainline
> > > > kernel without the SVA patches.  So it supports only one process for each
> > > > accelerator.
> > > > 
> > > > We have noticed the IOMMU aware mdev RFC announced recently [3].
> > > > 
> > > > The IOMMU aware mdev has similar idea but different intention comparing to
> > > > WarpDrive. It intends to dedicate part of the hardware resource to a VM.
> > > > And the design is supposed to be used with Scalable I/O Virtualization.
> > > > While sdmdev is intended to share the hardware resource with a big amount
> > > > of processes.  It just requires the hardware supporting address
> > > > translation per process (PCIE's PASID or ARM SMMU's substream ID).
> > > > 
> > > > But we don't see serious confliction on both design. We believe they can be
> > > > normalized as one.
> > > >   
> > > 
> > > So once again i do not understand why you are trying to do things
> > > this way. Kernel already have tons of example of everything you
> > > want to do without a new framework. Moreover i believe you are
> > > confuse by VFIO. To me VFIO is for VM not to create general device
> > > driver frame work.
> > 
> > VFIO is a userspace driver framework, the VM use case just happens to
> > be a rather prolific one.  VFIO was never intended to be solely a VM
> > device interface and has several other userspace users, notably DPDK
> > and SPDK, an NVMe backend in QEMU, a userspace NVMe driver, a ruby
> > wrapper, and perhaps others that I'm not aware of.  Whether vfio is
> > appropriate interface here might certainly still be a debatable topic,
> > but I would strongly disagree with your last sentence above.  Thanks,
> > 
> > Alex
> > 
> 
> Yes, that is also my standpoint here.
> 
> > > So here is your use case as i understand it. You have a device
> > > with a limited number of command queues (can be just one) and in
> > > some case it can support SVA/SVM (when hardware support it and it
> > > is not disabled). Final requirement is being able to schedule cmds
> > > from userspace without ioctl. All of this exists already exists
> > > upstream in few device drivers.
> > > 
> > > 
> > > So here is how every body else is doing it. Please explain why
> > > this does not work.
> > > 
> > > 1 Userspace open device file driver. Kernel device driver create
> > >   a context and associate it with on open. This context can be
> > >   uniq to the process and can bind hardware resources (like a
> > >   command queue) to the process.
> > > 2 Userspace bind/acquire a commands queue and initialize it with
> > >   an ioctl on the device file. Through that ioctl userspace can
> > >   be inform wether either SVA/SVM works for the device. If SVA/
> > >   SVM works then kernel device driver bind the process to the
> > >   device as part of this ioctl.
> > > 3 If SVM/SVA does not work userspace do an ioctl to create dma
> > >   buffer or something that does exactly the same thing.
> > > 4 Userspace mmap the command queue (mmap of the device file by
> > >   using informations gather at step 2)
> > > 5 Userspace can write commands into the queue it mapped
> > > 6 When userspace close the device file all resources are release
> > >   just like any existing device drivers.
> 
> Hi, Jerome,
> 
> Just one thing, as I said in the cover letter, dma-buf requires the application
> to use memory created by the driver for DMA. I did try the dma-buf way in
> WrapDrive (refer to [4] in the cover letter), it is a good backup for NOIOMMU
> mode or we cannot solve the problem in VFIO.
> 
> But, in many of my application scenario, the application already has some memory
> in hand, maybe allocated by the framework or libraries. Anyway, they don't get
> memory from my library, and they pass the poiter for data operation. And they
> may also have pointer in the buffer. Those pointer may be used by the
> accelerator. So I need hardware fully share the address space with the
> application. That is what dmabuf cannot do.

dmabuf can do that ... it is call uptr you can look at i915 for
instance. Still this does not answer my question above, why do
you need to be in VFIO to do any of the above thing ? Kernel has
tons of examples that does all of the above and are not in VFIO
(including usinng existing user pointer with device).

Cheers,
Jérôme

  reply	other threads:[~2018-09-06 13:31 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03  0:51 [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive Kenneth Lee
2018-09-03  0:51 ` [PATCH 1/7] vfio/sdmdev: Add documents for WarpDrive framework Kenneth Lee
2018-09-06 18:36   ` Randy Dunlap
2018-09-07  2:21     ` Kenneth Lee
2018-09-03  0:51 ` [PATCH 2/7] iommu: Add share domain interface in iommu for sdmdev Kenneth Lee
2018-09-03  0:52 ` [PATCH 3/7] vfio: add sdmdev support Kenneth Lee
2018-09-03  2:11   ` Randy Dunlap
2018-09-06  8:08     ` Kenneth Lee
2018-09-03  2:55   ` Lu Baolu
2018-09-06  9:01     ` Kenneth Lee
2018-09-04 15:31   ` [RFC PATCH] vfio: vfio_sdmdev_groups[] can be static kbuild test robot
2018-09-04 15:32   ` [PATCH 3/7] vfio: add sdmdev support kbuild test robot
2018-09-04 15:32   ` kbuild test robot
2018-09-05  7:27   ` Dan Carpenter
2018-09-03  0:52 ` [PATCH 4/7] crypto: add hisilicon Queue Manager driver Kenneth Lee
2018-09-03  2:15   ` Randy Dunlap
2018-09-06  9:08     ` Kenneth Lee
2018-09-03  0:52 ` [PATCH 5/7] crypto: Add Hisilicon Zip driver Kenneth Lee
2018-09-03  0:52 ` [PATCH 6/7] crypto: add sdmdev support to Hisilicon QM Kenneth Lee
2018-09-03  2:19   ` Randy Dunlap
2018-09-06  9:09     ` Kenneth Lee
2018-09-03  0:52 ` [PATCH 7/7] vfio/sdmdev: add user sample Kenneth Lee
2018-09-03  2:25   ` Randy Dunlap
2018-09-06  9:10     ` Kenneth Lee
2018-09-03  2:32 ` [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive Lu Baolu
2018-09-06  9:11   ` Kenneth Lee
2018-09-04 15:00 ` Jerome Glisse
2018-09-04 16:15   ` Alex Williamson
2018-09-06  9:45     ` Kenneth Lee
2018-09-06 13:31       ` Jerome Glisse [this message]
2018-09-07  4:01         ` Kenneth Lee
2018-09-07 16:53           ` Jerome Glisse
2018-09-07 17:55             ` Jean-Philippe Brucker
2018-09-07 18:04               ` Jerome Glisse
2018-09-10  3:28             ` Kenneth Lee
2018-09-10 14:54               ` Jerome Glisse
2018-09-11  2:42                 ` Kenneth Lee
2018-09-11  3:33                   ` Jerome Glisse
2018-09-11  6:40                     ` Kenneth Lee
2018-09-11 13:40                       ` Jerome Glisse
2018-09-13  8:32                         ` Kenneth Lee
2018-09-13 14:51                           ` Jerome Glisse
2018-09-14  3:12                             ` Kenneth Lee
2018-09-14 14:05                               ` Jerome Glisse
2018-09-14  6:50                             ` Tian, Kevin
2018-09-14 13:05                               ` Kenneth Lee
2018-09-14 14:13                               ` Jerome Glisse
2018-09-17  1:42 ` Jerome Glisse
2018-09-17  8:39   ` Kenneth Lee
2018-09-17 12:37     ` Jerome Glisse
2018-09-18  6:00       ` Kenneth Lee
2018-09-18 13:03         ` Jerome Glisse
2018-09-20  5:55           ` Kenneth Lee
2018-09-20 14:23             ` Jerome Glisse
2018-09-21 10:05               ` Kenneth Lee
2018-09-21 10:03   ` Kenneth Lee
2018-09-21 14:52     ` Jerome Glisse
2018-09-25  5:55       ` Kenneth Lee

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=20180906133133.GA3830@redhat.com \
    --to=jglisse@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=fanghao11@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-accelerators@lists.ozlabs.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=nek.in.cn@gmail.com \
    --cc=pombredanne@nexb.com \
    --cc=sanjay.k.kumar@intel.com \
    --cc=tglx@linutronix.de \
    --cc=wangzhou1@hisilicon.com \
    --cc=xuzaibo@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).