From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 23144A0548; Sun, 18 Apr 2021 17:10:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F1348410E5; Sun, 18 Apr 2021 17:10:53 +0200 (CEST) Received: from sender11-of-o51.zoho.eu (sender11-of-o51.zoho.eu [31.186.226.237]) by mails.dpdk.org (Postfix) with ESMTP id 93098410D7 for ; Sun, 18 Apr 2021 17:10:52 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; t=1618758638; cv=none; d=zohomail.eu; s=zohoarc; b=ONO1M9D6NQJkBhAj21irCYziZBENnNyNFYfTChYvSmkAlP6yxuT4Kvyvp2TaJu1iu8tPwe0TJHTHItSAziJEdstDrowBK1UngCigbkJc3zpM6ntWlnDkrLx6aMgAXzBjr+JfZu0gB6JpZLhGNECd3cIaQOwhjrpqeIqCNJLZDwU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1618758638; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=rbQXuyfxL/CyIxhkWcAyg12FvbU5pFKjvzIiiQ8N98A=; b=PK8Jm85+x7PppAaltOysYMIkakW5MQ5iKw/mha1OgtJ2jHnhFjtn0cMLswCZAEptbXFY9E20jxKDZbqR//TRdi2pAancThyNtFKl0RZjRZ5j/U3A4LGaBfpdr4hdZROimsfFV+pfvn2/MYHmx+Q9JKcZ411Jx2JufRVZ+lka390= ARC-Authentication-Results: i=1; mx.zohomail.eu; spf=pass smtp.mailfrom=liangma@liangbit.com; dmarc=pass header.from= header.from= Received: from DESKTOP-POQV63C.localdomain (51.37.188.134 [51.37.188.134]) by mx.zoho.eu with SMTPS id 161875863554450.151861576535225; Sun, 18 Apr 2021 17:10:35 +0200 (CEST) Date: Sun, 18 Apr 2021 16:10:32 +0100 From: Liang Ma To: Thomas Monjalon Cc: Maxime Coquelin , bruce.richardson@intel.com, jerinj@marvell.com, andrew.rybchenko@oktetlabs.ru, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, g.singh@nxp.com, radhac@marvell.com, vburru@marvell.com, Cheng Jiang , dev@dpdk.org, chenbo.xia@intel.com, jiayu.hu@intel.com, yvonnex.yang@intel.com, yinan.wang@intel.com, alexr@nvidia.com, shahafs@nvidia.com Message-ID: <20210418151032.GB41@DESKTOP-POQV63C.localdomain> References: <20210317054054.34616-1-Cheng1.jiang@intel.com> <23c4f6e7-4895-44b7-4ff0-3a02f9f3f86a@redhat.com> <2267082.chWHW8dCnR@thomas> <1700633.VhrhA6iQC3@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1700633.VhrhA6iQC3@thomas> User-Agent: Mutt/1.9.4 (2018-02-28) X-ZohoMailClient: External Subject: Re: [dpdk-dev] [PATCH] examples/vhost: fix ioat ring space in callbacks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Wed, Apr 07, 2021 at 10:43:36AM +0200, Thomas Monjalon wrote: > +Cc more people to start a discussion about a potential DMA API. > If you think it is interesting, we can start a fresh discussion thread. +1 that's ineresting to have a abstract layer of DMA offload engine. I would like join the discussion. please add me in the cc list in the new thread. > 07/04/2021 10:26, Thomas Monjalon: > > 07/04/2021 09:47, Maxime Coquelin: > > > > > > On 3/17/21 6:40 AM, Cheng Jiang wrote: > > > > We use ioat ring space for determining if ioat callbacks can enqueue a > > > > packet to ioat device. But there is one slot can't be used in ioat > > > > ring due to the ioat driver design, so we need to reduce one slot in > > > > ioat ring to prevent ring size mismatch in ioat callbacks. > [...] > > > > --- a/examples/vhost/ioat.c > > > > +++ b/examples/vhost/ioat.c > > > > @@ -113,7 +113,7 @@ open_ioat(const char *value) > > > > goto out; > > > > } > > > > rte_rawdev_start(dev_id); > > > > - cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE; > > > > + cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE - 1; > > > > > > That really comforts me in thinking we need a generic abstraction for > > > DMA devices. How is the application developer supposed to know that > > > the DMA driver has such weird limitations? > > > > Having a generic DMA API may be interesting. > > Do you know any other HW candidate for such an API? > > Do you think rte_memcpy can be used as a SW driver? > > >