From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 3967FA034F;
	Wed, 28 Jul 2021 13:13:51 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id B8A2340E64;
	Wed, 28 Jul 2021 13:13:50 +0200 (CEST)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151])
 by mails.dpdk.org (Postfix) with ESMTP id D90A140142
 for <dev@dpdk.org>; Wed, 28 Jul 2021 13:13:48 +0200 (CEST)
X-IronPort-AV: E=McAfee;i="6200,9189,10058"; a="192921380"
X-IronPort-AV: E=Sophos;i="5.84,276,1620716400"; d="scan'208";a="192921380"
Received: from fmsmga007.fm.intel.com ([10.253.24.52])
 by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 28 Jul 2021 04:13:47 -0700
X-IronPort-AV: E=Sophos;i="5.84,276,1620716400"; d="scan'208";a="437731280"
Received: from bricha3-mobl.ger.corp.intel.com ([10.252.30.136])
 by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA;
 28 Jul 2021 04:13:44 -0700
Date: Wed, 28 Jul 2021 12:13:41 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: Chengwen Feng <fengchengwen@huawei.com>
Cc: thomas@monjalon.net, ferruh.yigit@intel.com, jerinj@marvell.com,
 jerinjacobk@gmail.com, andrew.rybchenko@oktetlabs.ru, dev@dpdk.org,
 mb@smartsharesystems.com, nipun.gupta@nxp.com,
 hemant.agrawal@nxp.com, maxime.coquelin@redhat.com,
 honnappa.nagarahalli@arm.com, david.marchand@redhat.com,
 sburla@marvell.com, pkapoor@marvell.com, konstantin.ananyev@intel.com
Message-ID: <YQE75ZjolP5Rmt/O@bricha3-MOBL.ger.corp.intel.com>
References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com>
 <1627357200-15291-1-git-send-email-fengchengwen@huawei.com>
 <1627357200-15291-2-git-send-email-fengchengwen@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1627357200-15291-2-git-send-email-fengchengwen@huawei.com>
Subject: Re: [dpdk-dev] [PATCH v11 1/2] dmadev: introduce DMA device library
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Tue, Jul 27, 2021 at 11:39:59AM +0800, Chengwen Feng wrote:
> This patch introduce 'dmadevice' which is a generic type of DMA
> device.
> 
> The APIs of dmadev library exposes some generic operations which can
> enable configuration and I/O with the DMA devices.
> 
> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---

Thanks for this. Before it gets merged, I believe it needs to be split
further into multiple patches (say 4 or so) rather than adding the whole
lib in one go.

Normally, I believe the split would be something like:
* basic device structures and infrastructure e.g. alloc and release
  functions
* device config functions (and structures to go along with them)
  such as configure and queue_setup
* data plane functions

Documentation would be included in each of the patches, rather than done as
a block at the end.

Besides that, I have one small additional requests for the API. Based off
feedback for ioat driver, we added in the following function to that API,
and we probably need something similar in dmadev:

rte_ioat_burst_capacity()

For our implementation this returns the number of elements that can be
enqueued to the ring, at least for the current burst/batch of packets. We
did the API this way because there can be additional limits beyond ring
size on each individual burst beyond just the raw ring capacity, e.g. even
if there are 4k ring elements free, there may be limits on the max burst
size the hardware can do, or limits on the number of outstanding
batches etc.

Therefore can I request the addition of rte_dmadev_burst_capacity() [or
something similarly named] to the basic dmadev API set. For most hardware,
I think this will likely be the remaining free ring size, but I don't
believe the API should commit to that. The use case it was added for was to
enable an application which needs to do a multi-copy operation to check
that all copies can fit or not before enqueuing the first one. This is
important for hardware that doesn't have scatter-gather list support.

/Bruce

PS: One typo in code flagged below too.

<snip>
> + */
> +enum rte_dma_status_code {
> +	RTE_DMA_STATUS_SUCCESSFUL,
> +	/**< The operation completed successfully. */
> +	RTE_DMA_STATUS_USRER_ABORT,

              Typo here ^^^