DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Liang, Cunming" <cunming.liang@intel.com>
Cc: "Fu, Patrick" <patrick.fu@intel.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	 "dev@dpdk.org" <dev@dpdk.org>,
	"Ye, Xiaolong" <xiaolong.ye@intel.com>,
	"Hu, Jiayu" <jiayu.hu@intel.com>,
	"Wang, Zhihong" <zhihong.wang@intel.com>
Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK vHost with DMA Engines
Date: Mon, 20 Apr 2020 16:43:13 +0530	[thread overview]
Message-ID: <CALBAE1Mr-YNHy5M5JD3gr=7dObmnUo0D-MuGMSs30yQ5q9GAMA@mail.gmail.com> (raw)
In-Reply-To: <BYAPR11MB2552EE92F1A6CFF1D3C86A92F9D40@BYAPR11MB2552.namprd11.prod.outlook.com>

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?



>
> It was not asking to writing two drivers. Each driver remains to offer provider for its own device class, which is independent. App provides the intension (adapter) to associate various device capability to vhost session.
>
> > If vhost is the first consumer of DMA needed then I think, it make sense to add
> > dmadev first.
> On the other hand, it's risky to define 'dmadev' according to vhost's flavor before not getting aware of any other candidates. Comparing with kern Async TX DMA API (async_memcpy), RFC is very much focus on S/G buffer but not a async_memcpy.
>
> > The rawdev DMA driver to dmadev DMA driver conversion will be the driver owner
> > job.
> It's true when it's necessary. Even that is the case, it's better for vhost to be independent with any device model, moreover vhost usage doesn't have broad enough coverage for a new device class.
>
> > I think, it makes sense to define the dmadev API and then costume by virtio to
> > avoid integration issues.
> Vhost is a library but not a app. We'd better avoid to intro either overkill integration logic or extra device model dependence.
>
> Thanks,
> Steve
>
> >
> >
> >
> > >
> > > Thanks,
> > >
> > > Patrick
> > >

  reply	other threads:[~2020-04-20 11:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17  7:26 Fu, Patrick
2020-04-17  8:01 ` Jerin Jacob
2020-04-17  8:29   ` Fu, Patrick
2020-04-17  8:40     ` Maxime Coquelin
2020-04-17  9:26       ` Fu, Patrick
2020-04-17  9:54         ` Jerin Jacob
2020-04-20  7:59           ` Liang, Cunming
2020-04-20 11:13             ` Jerin Jacob [this message]
2020-04-20 11:44               ` Maxime Coquelin
2020-04-20 12:08                 ` Jerin Jacob
2020-04-20 12:10                   ` Maxime Coquelin
2020-04-20 12:15                     ` Jerin Jacob
2020-04-21  2:44                       ` Fu, Patrick
2020-04-21  6:04                         ` Jerin Jacob
2020-04-21  8:30                           ` Liang, Cunming
2020-04-21  9:05                             ` Jerin Jacob
2020-04-20 11:47             ` Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALBAE1Mr-YNHy5M5JD3gr=7dObmnUo0D-MuGMSs30yQ5q9GAMA@mail.gmail.com' \
    --to=jerinjacobk@gmail.com \
    --cc=cunming.liang@intel.com \
    --cc=dev@dpdk.org \
    --cc=jiayu.hu@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=patrick.fu@intel.com \
    --cc=xiaolong.ye@intel.com \
    --cc=zhihong.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).