Re: [dpdk-dev] [RFC v2 2/2] net/vhost_dma: add vHost DMA driver

["Hu, Jiayu" <jiayu.hu@intel.com>]

Hi Maxime,

Thanks for your suggestions. Replies are inline.

> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, December 17, 2019 6:20 PM
> To: Hu, Jiayu <jiayu.hu@intel.com>; dev@dpdk.org
> Cc: Bie, Tiwei <tiwei.bie@intel.com>; Wang, Zhihong
> <zhihong.wang@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; jerinj@marvell.com
> Subject: Re: [dpdk-dev] [RFC v2 2/2] net/vhost_dma: add vHost DMA driver
> 
> 
> >> The PMD has 4 parameters.
> >>  - iface: The parameter is used to specify a path to connect to a
> >>  	front end device.
> >>  - queues: The parameter is used to specify the number of the queues
> >>  	front end device has (Default is 1).
> >>  - client: The parameter is used to specify the vhost port working as
> >>  	client mode or server mode (Default is server mode).
> >>  - dmas: This parameter is used to specify the assigned DMA device
> >>  	of a queue.
> >>
> >> Here is an example.
> >> $ ./testpmd -c f -n 4 \
> >> --vdev
> 'dma_vhost0,iface=/tmp/sock0,queues=1,dmas=txq0@00:04.0,client=0'
> >
> > dma_vhost0 is not a good name, you have to mention it is net specific.
> >
> > Is there a tool to list available DMA engines?
> 
> Thinking at it again, wouldn't it be possible that the user doesn't
> specify a specific DMA device ID, but instead allocate one device
> at init time by specifying all the capabilities the DMA device need
> to match?
> 
> If no DMA device available with matching capabilities, then fallback to
> SW mode.

I think it’s a good way to allocate DMAs by capabilities, like NUMA node. But
the problem is how to express the relationship between queues and DMAs.
As RX/TX is per-queue basis, we need to know if a queue needs DMA acceleration
or not. Current vdev parameters explicitly specify which queue uses which
DMA; if we use DMA capability, will the parameters look too complex? Like
dmas={txq0@(numa0, other capabilities);txq1@(numa0, ...)}

Any suggestions?

> 
> Also, I think we don't want to call directly IOAT API directly here, but
> instead introduce a DMA library so that the Vhost DMA stuff isn't vendor
> specific.

As I know, all DMA engines in DPDK are implemented as rawdev and there is no
unified API for them. If it's necessary, we can provide a DMA library for them
in the future, so that more scenarios can benefit from the DMA engines.

IMO, vhost is one of consumers of the DMA engines, so the DMA library doesn't
have to be inside vhost; in addition, we just know IOAT can accelerate vhost, but
don't know about other DMA engines. Therefore, at this point, I think it's OK to
directly call IOAT API. Furthermore, we can replace IOAT specific API in vhost PMD,
if there is a DMA library in the future; as long as current vdev parameters
for DMA are generic enough, internal API replacement will not be visible to users.

How do you think?

Regards,
Jiayu

> 
> Adding a few ARM people in cc, to know whether they have plan/interrest
> in supporting DMA acceleration for Vhost.
> 
> Regards,
> Maxime
>