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 9588CA0561; Mon, 20 Apr 2020 14:09:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06D191C1DE; Mon, 20 Apr 2020 14:09:14 +0200 (CEST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by dpdk.org (Postfix) with ESMTP id 504751C1DD for ; Mon, 20 Apr 2020 14:09:13 +0200 (CEST) Received: by mail-io1-f48.google.com with SMTP id b12so10604441ion.8 for ; Mon, 20 Apr 2020 05:09:13 -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=fX8t2LNLEXVM0ci6EALESAG4VtKGUWq1IYvJKYUmjgM=; b=JwOmxbRtbVNsFTq34til+ckFPPSVe++LwefiKBuKMVsiX32ifvYWrlC4GVCElPU+ZK HyfXLUL57N7ySKVyDmN2KhaBx3ffgt8UJnGlnC2EyDjl0B+9meoL7s5JLALO9wfCJTqP dIlsin4Gre7L/T1cYhDU1LvdNd7T+/K4P8CPHT/nspJNW0Xb6xKm5e/AiZCMofWQIK3g AfbjZFSn5NWf1tl2Do80sPxMSiOtJsqhMWJcNo4IZdVhAD4VYO2MqgoUrP1oNW8VCmw5 IE5VuP8MdvPn1lrCNVLlkutWdk5rn/mJODV88OX0GlaPp3HcyLdP7Uyh+18vBS7A79FA L5XA== 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=fX8t2LNLEXVM0ci6EALESAG4VtKGUWq1IYvJKYUmjgM=; b=GJo6vzR4PAq/4Okr2GQ0QSLSZ3UyBpCI0crIcvCLgR4Fp7QkSJg8F4Jg38U7t4d0kH mqYN24i//DWmp1SI2n06zO2PuCBZ79zFOQPQQjzxAbt9Jj4KlazAd2UfIuLNScRSUe9S cT56JF9p6gJAY0vDPiYJbANKSMikE8JvqowfYc6LnG6eexywGzWx5HQvAXw9gYUKfmiG 0aG6bAd3+GadyVijrta62ep0TMwSh5puJMQcPZYQuL373ZXmw8lTlSHuvBzbB3BXj3+p cA9mHyVQLmxN9l1aXflJS8i+TuTzfLcjUjWaTZzDhKsPXZkdQhV3mbGxUxxxZ3E107lZ LQTw== X-Gm-Message-State: AGi0PuY8sDh3QNkcV/WJz+evrkxd8FFNebIqF+527e/g7wUAECe27l9t CLOOVSy481AmLQjTb+9L2Zj3rtvV2sbFw0MIOYc= X-Google-Smtp-Source: APiQypLHbcKBtzHhUvVtXJ1xRYXZdrrYHdIog5MHEMVTYSDL5egP8MuYCZ3PIDN8zPHR0opDjJC/P7ZsmaOwCGHq+Jg= X-Received: by 2002:a02:455:: with SMTP id 82mr15069795jab.112.1587384551227; Mon, 20 Apr 2020 05:09:11 -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: <0aaa4b51-f705-1dc4-db60-00e9084db2ea@redhat.com> From: Jerin Jacob Date: Mon, 20 Apr 2020 17:38:55 +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: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 ; Wan= g, > >>> Zhihong ; Liang, Cunming > >>> Subject: Re: [dpdk-dev] [RFC] Accelerating Data Movement for DPDK vHo= st with > >>> DMA Engines > >>> > >>> On Fri, Apr 17, 2020 at 2:56 PM Fu, Patrick wr= ote: > >>>> > >>>> > >> [...] > >>>>>> > >>>>>> 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 n= o objection to > >>> make the dmadev. However, what we currently want to do is creating th= e async > >>> data path for vhost, and we actually have no preference to the underl= ying DMA > >>> device model. I believe our current design of the API proto type /dat= a 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. On= e for vhost > >>> and other one for rawdev. > >> It's the most simplest case if statically 1:1 mapping driver (e.g. {po= rt, queue}) to a vhost session {vid, qid}. However, it's not enough scalabl= e to integrate device model with vhost library. There're a few intentions b= elong to app logic rather than driver, e.g. 1:N load balancing, various dev= ice 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*