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 DF5B6A0561; Tue, 21 Apr 2020 08:04:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 650C31D67F; Tue, 21 Apr 2020 08:04:27 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 3C59A1C1D8 for ; Tue, 21 Apr 2020 08:04:26 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id o127so13825633iof.0 for ; Mon, 20 Apr 2020 23:04:26 -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; bh=yew8aFIubMUuviz1rPKrIokyIiuZvUOSP6vTZHcDp7s=; b=s7C28EiwaRuIYNlD0nvd3dcQliToPVSJHEX+CkFDECMRKKdFPynuUDiDXND66k+zEf JRODYFgmxKE9dItsO/TQal4nMsKLaZRQd1cOD94dwICX8of4S12ZQjxMv5RTaSQO14pe wlvlMdYaTIU+kOj5+/X5WQVmqSmgOnGsLA3YiqmEcCWsZcPZOFAJrFec/i2DJw4pNn/v Q4+ly5OTf+UYMHzKO4RULji0s2h4FUhGnlfumF26Nnrj4iW6Cc0mOaoRNtv9UIiYa+EW /9c/BABW4vJ8rs+ZTx0A//ID5+NB2FMmQUunBccj+uJVyCJ5dlhyGqmQsexItBeS/Ng9 sE5Q== 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; bh=yew8aFIubMUuviz1rPKrIokyIiuZvUOSP6vTZHcDp7s=; b=Ml5XzzPnYkAS75A6vRimvvTd/kAszNYq4RBwA+mm4jR8SW01v9A1/haTqA53emGgb2 gNjKyaxDBGIpDcIB6MmGJrDTEiwHBNQpjNwi//EAlLVKuDAQwl7TReRkfVs3eeTv9/mZ 1EAsYd2wSsGDDd5zx4feqqMkefvJDp9oqoMOPbDgFbLH5jil8Bt+H3eompL1SLWQFrBx b+IYJ9YPHgZh4d1AS5xcPeh7FT4xjQeKgbXAQgz81NlhPRmdW5DVGkdN63DibDjoV966 KcvYGhADd/ZHsbO/vyMOSn91FCE/o9HxNPi0OuTUPmgF7+XB/FPOslznUgGphhoHZywa l+xA== X-Gm-Message-State: AGi0PublGo0JKxfZWn3eWieR2gfnQ/lqWdr3+wdX8Flc9RRYBjAjvOzz SopQ+l9irImqqi/vEFEVcMVTAHtwC/LMEiYpAh4= X-Google-Smtp-Source: APiQypJwQnTEFOcym0ZXJL/Qf2tUnbdWVTMRg/rFUCdD3bEgEZzzCj4aDNb+8iq0NzaRF6bUXAjErYgfdSt+NWQJPuE= X-Received: by 2002:a02:ac94:: with SMTP id x20mr18573628jan.133.1587449065445; Mon, 20 Apr 2020 23:04:25 -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> <0aaa4b51-f705-1dc4-db60-00e9084db2ea@redhat.com> <89B17B9B05A1964E8D40D6090018F2815127AE8D@SHSMSX107.ccr.corp.intel.com> In-Reply-To: <89B17B9B05A1964E8D40D6090018F2815127AE8D@SHSMSX107.ccr.corp.intel.com> From: Jerin Jacob Date: Tue, 21 Apr 2020 11:34:09 +0530 Message-ID: To: "Fu, Patrick" Cc: Maxime Coquelin , "Liang, Cunming" , "dev@dpdk.org" , "Ye, Xiaolong" , "Hu, Jiayu" , "Wang, Zhihong" Content-Type: text/plain; charset="UTF-8" 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 Tue, Apr 21, 2020 at 8:14 AM Fu, Patrick wrote: > > Hi Jerin Hi Patrick, > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Monday, April 20, 2020 8:15 PM > > To: Maxime Coquelin > > Cc: Liang, Cunming ; Fu, Patrick > > ; dev@dpdk.org; Ye, Xiaolong > > ; Hu, Jiayu ; Wang, Zhihong > > > > Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK vHost > > with DMA Engines > > > > On Mon, Apr 20, 2020 at 5:40 PM Maxime Coquelin > > wrote: > > > > > > > > > > > > On 4/20/20 2:08 PM, Jerin Jacob wrote: > > > > On Mon, Apr 20, 2020 at 5:14 PM Maxime Coquelin > > > > wrote: > > > >> > > > >> > > > >> > > > >> On 4/20/20 1:13 PM, Jerin Jacob wrote: > > > >>> On Mon, Apr 20, 2020 at 1:29 PM Liang, Cunming > > wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>>> -----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 > > 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 > > > It most likely that IOAT could be leveraged as the first demonstration on the async DMA acceleration for vHOST. However, this is neither a limitation nor do we design this RFC specifically for IOAT. > With current RFC design, we will need applications to implement callbacks (which will call into the IOAT pmd in IOAT case) that can work with vHost async path. Then it would be calling some PMD specific APIs for dpaa2_qdma, octeontx2_dma, ioat and there will issue with integrating DMA consumer as vHOST and another consumer together. The correct approach is to create a new class for dma like Linux and vHOST consume as a client so that integration aspects are intact. > > Thanks, > > Patrick > >