From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 01F00A0561; Mon, 20 Apr 2020 13:13:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E62FC1C234; Mon, 20 Apr 2020 13:13:30 +0200 (CEST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by dpdk.org (Postfix) with ESMTP id EF4B71C231 for ; Mon, 20 Apr 2020 13:13:29 +0200 (CEST) Received: by mail-io1-f47.google.com with SMTP id w4so3254616ioc.6 for ; Mon, 20 Apr 2020 04:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Iy7ugZuC+cOuWAnRzVB86630+deS20nzbWCYv/ufm/Q=; b=of5S5goFka/ZszP5u9duOi4XZphgxdpF+wip6lGrtmptVnBu6DhTGv7/q/1IfN8YX/ 6Ac+qYokrbLqkf2QGChdNaCcjof/coGsWN1llzrjNVKc76M3gjeB792WIhf7Grw1m0zo iUg0KFNlmT9vESy+LippQLuJfUYgWZGwyfEsd694tgI6LRfVOi9zVluRTPPZLPqdfCXZ 5TzC00db4bMr4BulcQvFn3isfIeBr1kT/q48+PximVX39J0gk3Qkhhka7LGW7em5KhW3 YB/2daNYaTSz8EBVzVbOyJ/qktmzOkOm8gFYzyiwaGaU8+4O7TlEBy7ObAUL6PHRlLmI e6cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Iy7ugZuC+cOuWAnRzVB86630+deS20nzbWCYv/ufm/Q=; b=WCQKbLqkONRQpnj+hDofZsiXkaHfIxT/5Ol4CttjuC1eypSgVYWqfk67v9n0LKIJMT gI7WWPJMmCDUuq3Huj9zHuqhOsVieI0HnyJnhjYvelzG0MShPETESqwAbdQ7aSoy2xIe /M5aoS9PsjwyxDGdhbPQ2RC2/q5mSzQtK4Ezf/bigyYksiC97xrpWMR2SULUOVruswC3 Q41T6nhqD5q+xHHijpac0SX5YhRzC2oz9kEW4XBkLEh1nSadZyfVD081sBoHGDBfD4qK 048d9prRkeOZ55AxK09HAprk2cBkBvZE5mSkmUe8ZOSgui+XPhZBWtgYCVMeH2QXrtII JspQ== X-Gm-Message-State: AGi0PubzT5q9enV8RZGywMsoUF/53dfm+cpxcPE+au7tdpFxy2MuRCxd Y3LbyzvN97v7dkJ6OlyD+QUJUwDgU4Lx0E6iuaw= X-Google-Smtp-Source: APiQypKNKLI3DcT8LBesJElPTs7E4dc3cmT/ELu5B9WxIGRSRNLZPZdcCAAERAGaY48f0QA9M2SUxz3gjwHxdgSomxU= X-Received: by 2002:a05:6602:2e0b:: with SMTP id o11mr11947417iow.94.1587381209116; Mon, 20 Apr 2020 04:13:29 -0700 (PDT) MIME-Version: 1.0 References: <89B17B9B05A1964E8D40D6090018F28151277ADF@SHSMSX107.ccr.corp.intel.com> <89B17B9B05A1964E8D40D6090018F28151277C5C@SHSMSX107.ccr.corp.intel.com> <8e4691c5-3e58-fb5d-f1f5-6b9c994c3949@redhat.com> <89B17B9B05A1964E8D40D6090018F28151277D4F@SHSMSX107.ccr.corp.intel.com> In-Reply-To: From: Jerin Jacob Date: Mon, 20 Apr 2020 16:43:13 +0530 Message-ID: To: "Liang, Cunming" Cc: "Fu, Patrick" , Maxime Coquelin , "dev@dpdk.org" , "Ye, Xiaolong" , "Hu, Jiayu" , "Wang, Zhihong" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK vHost with DMA Engines X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Apr 20, 2020 at 1:29 PM Liang, Cunming wr= ote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Friday, April 17, 2020 5:55 PM > > To: Fu, Patrick > > Cc: Maxime Coquelin ; dev@dpdk.org; Ye, > > Xiaolong ; Hu, Jiayu ; Wang, > > Zhihong ; Liang, Cunming > > 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 wrot= e: > > > > > > > [...] > > > > > > > > > > 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 discusse= d > > > > 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 di= rectly. > > > > > > > > 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 underlyi= ng 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 t= o integrate device model with vhost library. There're a few intentions belo= ng 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 pr= ovider for its own device class, which is independent. App provides the int= ension (adapter) to associate various device capability to vhost session. > > > If vhost is the first consumer of DMA needed then I think, it make sens= e to add > > dmadev first. > On the other hand, it's risky to define 'dmadev' according to vhost's fla= vor before not getting aware of any other candidates. Comparing with kern A= sync TX DMA API (async_memcpy), RFC is very much focus on S/G buffer but no= t a async_memcpy. > > > The rawdev DMA driver to dmadev DMA driver conversion will be the drive= r owner > > job. > It's true when it's necessary. Even that is the case, it's better for vho= st to be independent with any device model, moreover vhost usage doesn't ha= ve broad enough coverage for a new device class. > > > I think, it makes sense to define the dmadev API and then costume by vi= rtio to > > avoid integration issues. > Vhost is a library but not a app. We'd better avoid to intro either overk= ill integration logic or extra device model dependence. > > Thanks, > Steve > > > > > > > > > > > > > Thanks, > > > > > > Patrick > > >