Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK vHost with DMA Engines

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 4/20/20 2:08 PM, Jerin Jacob wrote:
> On Mon, Apr 20, 2020 at 5:14 PM Maxime Coquelin
> <maxime.coquelin@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.liang@intel.com> wrote:
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Jerin Jacob <jerinjacobk@gmail.com>
>>>>> Sent: Friday, April 17, 2020 5:55 PM
>>>>> To: Fu, Patrick <patrick.fu@intel.com>
>>>>> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>; dev@dpdk.org; Ye,
>>>>> Xiaolong <xiaolong.ye@intel.com>; Hu, Jiayu <jiayu.hu@intel.com>; Wang,
>>>>> Zhihong <zhihong.wang@intel.com>; Liang, Cunming <cunming.liang@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.fu@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.

Maxime