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 E14D9A0C40; Thu, 29 Jul 2021 11:15:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6188940687; Thu, 29 Jul 2021 11:15:16 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 5850B40041 for ; Thu, 29 Jul 2021 11:15:14 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10059"; a="212873924" X-IronPort-AV: E=Sophos;i="5.84,278,1620716400"; d="scan'208";a="212873924" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2021 02:15:13 -0700 X-IronPort-AV: E=Sophos;i="5.84,278,1620716400"; d="scan'208";a="476272563" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.31.36]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 29 Jul 2021 02:15:09 -0700 Date: Thu, 29 Jul 2021 10:15:06 +0100 From: Bruce Richardson To: fengchengwen 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: 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> <9da78c1f-c2e4-cf71-9d07-dd539a16c1d0@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9da78c1f-c2e4-cf71-9d07-dd539a16c1d0@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jul 29, 2021 at 09:26:31AM +0800, fengchengwen wrote: > Thanks, inline comment > > On 2021/7/28 19:13, Bruce Richardson wrote: > > 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 > >> Acked-by: Bruce Richardson > >> Acked-by: Morten Brørup > >> --- > > > > 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 > > > > I will try for it > Maybe one patch for public file, one for pmd header file, one for > implementation, and last for doc. > > > 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. > > Remaining capacity can be inferred by ring_idx which return from enqueue and > dequeue APIs. > So I don't think this API needs to be added. > Yes, the app can always track it itself, but I still see value in adding this API. However, so long as you are open to having it added later, it doesn't matter if it's not present in the first versions of this API merged in. /Bruce