Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjac...@gmail.com>
> Sent: Tuesday, April 21, 2020 2:04 PM
> To: Fu, Patrick <patrick...@intel.com>
> Cc: Maxime Coquelin <maxime.coque...@redhat.com>; Liang, Cunming
> <cunming.li...@intel.com>; dev@dpdk.org; Ye, Xiaolong
> <xiaolong...@intel.com>; Hu, Jiayu <jiayu...@intel.com>; Wang, Zhihong
> <zhihong.w...@intel.com>
> Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK vHost with
> DMA Engines
>
> On Tue, Apr 21, 2020 at 8:14 AM Fu, Patrick <patrick...@intel.com> wrote:
> >
> > Hi Jerin
>
> Hi Patrick,
>
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjac...@gmail.com>
> > > Sent: Monday, April 20, 2020 8:15 PM
> > > To: Maxime Coquelin <maxime.coque...@redhat.com>
> > > Cc: Liang, Cunming <cunming.li...@intel.com>; Fu, Patrick
> > > <patrick...@intel.com>; dev@dpdk.org; Ye, Xiaolong
> > > <xiaolong...@intel.com>; Hu, Jiayu <jiayu...@intel.com>; Wang,
> > > Zhihong <zhihong.w...@intel.com>
> > > Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK
> > > vHost with DMA Engines
> > >
> > > On Mon, Apr 20, 2020 at 5:40 PM Maxime Coquelin
> > > <maxime.coque...@redhat.com> wrote:
> > > >
> > > >
> > > >
> > > > On 4/20/20 2:08 PM, Jerin Jacob wrote:
> > > > > On Mon, Apr 20, 2020 at 5:14 PM Maxime Coquelin
> > > > > <maxime.coque...@redhat.com> wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> On 4/20/20 1:13 PM, Jerin Jacob wrote:
> > > > >>> On Mon, Apr 20, 2020 at 1:29 PM Liang, Cunming
> > > <cunming.li...@intel.com> wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: Jerin Jacob <jerinjac...@gmail.com>
> > > > >>>>> Sent: Friday, April 17, 2020 5:55 PM
> > > > >>>>> To: Fu, Patrick <patrick...@intel.com>
> > > > >>>>> Cc: Maxime Coquelin <maxime.coque...@redhat.com>;
> > > dev@dpdk.org;
> > > > >>>>> Ye, Xiaolong <xiaolong...@intel.com>; Hu, Jiayu
> > > > >>>>> <jiayu...@intel.com>; Wang, Zhihong
> > > > >>>>> <zhihong.w...@intel.com>; Liang, Cunming
> > > > >>>>> <cunming.li...@intel.com>
> > > > >>>>> Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for
> > > > >>>>> DPDK vHost with DMA Engines
> > > > >>>>>
> > > > >>>>> On Fri, Apr 17, 2020 at 2:56 PM Fu, Patrick
> > > > >>>>> <patrick...@intel.com>
> > > wrote:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>> [...]
> > > > >>>>>>>>
> > > > >>>>>>>> I believe it doesn't conflict. The purpose of this RFC is
> > > > >>>>>>>> to create an async
> > > > >>>>>>> data path in vhost-user and provide a way for applications
> > > > >>>>>>> to work with this new path. dmadev is another topic which
> > > > >>>>>>> could be discussed separately. If we do have the dmadev
> > > > >>>>>>> available in the future, this vhost async data path could
> > > > >>>>>>> certainly be backed by the new dma abstraction without
> > > > >>>>>>> major interface
> > > change.
> > > > >>>>>>>
> > > > >>>>>>> Maybe that one advantage of a dmadev class is that it
> > > > >>>>>>> would be easier and more transparent for the application to
> consume.
> > > > >>>>>>>
> > > > >>>>>>> The application would register some DMA devices, pass them
> > > > >>>>>>> to the Vhost library, and then
> > > > >>>>>>> rte_vhost_submit_enqueue_burst and
> > > > >>>>>>> rte_vhost_poll_enqueue_completed would call the dmadev
> > > callbacks directly.
> > > > >>>>>>>
> > > > >>>>>>> Do you think that could work?
> > > > >>>>>>>
> > > > >>>>>> Yes, this is a workable model. As I said in previous reply,
> > > > >>>>>> I have no objection to
> > > > >>>>> make the dmadev. However, what we currently want to do is
> > > > >>>>> creating the async data path for vhost, and we actually have
> > > > >>>>> no preference to the underlying DMA device model. I believe
> > > > >>>>> our current design of the API proto type /data structures
> > > > >>>>> are quite common for various DMA acceleration solutions and
> > > > >>>>> there is no
> > > blocker for any new DMA device to adapt to these APIs or extend to a
> > > new one.
> > > > >>>>>
> > > > >>>>> IMO, as a driver writer, we should not be writing TWO DMA
> > > > >>>>> driver. One for vhost and other one for rawdev.
> > > > >>>> It's the most simplest case if statically 1:1 mapping driver
> > > > >>>> (e.g. {port,
> > > queue}) to a vhost session {vid, qid}. However, it's not enough
> > > scalable to integrate device model with vhost library. There're a
> > > few intentions belong to app logic rather than driver, e.g. 1:N load
> > > balancing, various device type usages (e.g. vhost zcopy via ethdev) and
> > > etc.
> > > > >>>
> > > > >>>
> > > > >>> Before moving to reply to comments, Which DMA engine you are
> > > > >>> planning to integrate with vHOST?
> > > > >>> Is is ioat? if not ioat(drivers/raw/ioat/), How do you think,
> > > > >>> how we can integrate this IOAT DMA engine to vHOST as a use case?
> > > > >>>
> > > > >>
> > > > >> I guess it could be done in the vhost example.
> > > > >
> > > > >
> > > > > Could not see any reference to DMA in examples/vhost*
> > > > >
> > > >
> > > > That's because we are discussing the API to introduce DMA support
> > > > in this exact mail thread, nothing has been merged yet.
> > >
> > > Some confusion here. Original question was, # This is an RFC for DMA
> > > support in vHOST # What is the underneath DMA engine planned for
> > > hooking to vHOST async API as a "implementation" for this RFC?
> > > # If it ioat, How does the integration work with ioat exiting
> > > rawdriver and new API?
> > > # if it not ioat, What it takes to add support ioat based DMA engine
> > > to vHOST aysnc API
> > >
> > It most likely that IOAT could be leveraged as the first demonstration on
> > the
> async DMA acceleration for vHOST. However, this is neither a limitation nor
> do we
> design this RFC specifically for IOAT.
> > With current RFC design, we will need applications to implement callbacks
> (which will call into the IOAT pmd in IOAT case) that can work with vHost
> async
> path.
>
> Then it would be calling some PMD specific APIs for dpaa2_qdma, octeontx2_dma,
> ioat and there will issue with integrating DMA consumer as vHOST and another
> consumer together.
The main effort is to intro async-mode API for vhost allowing external hooks
for raw buffer (VM and/or host app) access regardless of virtio ring layout.
It never forces ops to leverage DMA device, think about rxtx_callback of
ethdev. That's pretty much app's or helper library's flavor of the ops.
If not comfortable to demo ops with dma, that's fine for us to focus on CPU
only as a hook provider in the sample, and omit 'w/ DMA engine' from RFC.
> The correct approach is to create a new class for dma like Linux and vHOST
> consume as a client so that integration aspects are intact.
I'm curious what's the usages when dpaa2_qdma, octeontx2_dma, ioat being
introduce into raw device, why these usage don’t have excuse, but you believe
vhost has.
They exists for a while as a raw device. If it's do necessary, they've already
built a class...
As you said, vhost is one of the client to consume but not owns device class,
moreover these raw device is not the only 'server' to vhost.
For your concern, it worth a separate conversation but not limited for vhost
case.
Thanks,
Steve
>
>
>
>
>
> >
> > Thanks,
> >
> > Patrick
> >
> >
