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 correct approach is to create a new class for dma like Linux and
vHOST consume as a client so that integration aspects are intact.
>
> Thanks,
>
> Patrick
>
>
