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 D3BB5A0561; Mon, 20 Apr 2020 14:15:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AFE0A1C1DE; Mon, 20 Apr 2020 14:15:43 +0200 (CEST) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com [209.85.166.173]) by dpdk.org (Postfix) with ESMTP id E1F511C1EE for ; Mon, 20 Apr 2020 14:15:42 +0200 (CEST) Received: by mail-il1-f173.google.com with SMTP id s10so8740282iln.11 for ; Mon, 20 Apr 2020 05:15:42 -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=FajHwy3ak3IsZLqIlFDNKZ1UGmioNvndTE+D+oDlE4s=; b=fOLWIcLiVUArvY/5lr6JdyjWD8/wHC3a1b1zHap7M2NVpiJQPQXP0HRscTsuzoh5Cq FKhvJKSkKTuEsZ1g2g6pqbcsK9tuvev9AuTgXA9IpSIAIPW9TmNgxsZYURPyzckyjhPG y3wDf7FAaGVJbML275N20MTnAUOwVLfuz/BT3nksaNgvoGAdntbTUCGwCGqhUpCi2jD8 FxFF8H/cRQZ+rs6nrbKWNfAWhVlQvHptvjuCSQtzrF1lollnjBWSHV+qFS3K5hVRWSwP CTrEBkRBmf//l2qhWz6v2zX7JchkJUKhGUHpCQPWkQHybKK3T2ItTdL5fzNeH3lZWHt3 VoHQ== 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=FajHwy3ak3IsZLqIlFDNKZ1UGmioNvndTE+D+oDlE4s=; b=UlIXBHJkVQRwnTLmp3du9sB9JBecaFeawuf3p5ASxhm7y38BvrWtbcDPxouSQVslgk 1GnbVMWhEPEudmzPvL2zs4Nx1T8JE3DgZVkHIjV1RkaRNvCybLc6YPa/x/yQsqL2/jqt m8Pkl6EGzrXV7dBFtRa5ycOPt9VyoUO5kYYDLmYuyKPqqLfIm/PDh9EEUtjSUqRr7UUK UHFDPGMn8Nba3DymiVJ2bG2V+TjbpX/r1v42BBiumTJoQNAK1OpY38RJNLrI0YOu1hHV FEhjWwx5N+OOYoiy+SlbTscN8LdiCFw/WT/NMj3uAVULX3c4eAsb4gW846gofg31Cr0J kOhg== X-Gm-Message-State: AGi0PuY2pib0S1PalfWom+Pc/987bkbHs2eJHWX+fHHFDeqHnJvkKlcm lMBUHnaVgnIMR/vv0Sh/LSoDEJqAf0fKnpXyfVY= X-Google-Smtp-Source: APiQypK2hPZIQx8GwYnm6ARRjqiOZgNN5XCSnOaFrWsgxJM12HF/j6GSztpuUqtXCqw1IFcA+k7JV1npwKPtnDgmAwQ= X-Received: by 2002:a92:9edb:: with SMTP id s88mr15940065ilk.294.1587384942276; Mon, 20 Apr 2020 05:15:42 -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> In-Reply-To: From: Jerin Jacob Date: Mon, 20 Apr 2020 17:45:26 +0530 Message-ID: To: Maxime Coquelin Cc: "Liang, Cunming" , "Fu, Patrick" , "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 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 ; W= ang, > >>>>> Zhihong ; Liang, Cunming > >>>>> Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK v= Host 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 wor= k > >>>>>>> with this new path. dmadev is another topic which could be discus= sed > >>>>>>> separately. If we do have the dmadev available in the future, thi= s > >>>>>>> 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 unde= rlying DMA > >>>>> device model. I believe our current design of the API proto type /d= ata structures > >>>>> are quite common for various DMA acceleration solutions and there i= s no blocker > >>>>> for any new DMA device to adapt to these APIs or extend to a new on= e. > >>>>> > >>>>> 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 scala= ble 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 d= evice 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 > > Maxime >