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
>
> Maxime
>
