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 0CE75A0C4F; Tue, 13 Jul 2021 16:29:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A46DF410F0; Tue, 13 Jul 2021 16:29:00 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 51959410DC for ; Tue, 13 Jul 2021 16:28:58 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10043"; a="210214822" X-IronPort-AV: E=Sophos;i="5.84,236,1620716400"; d="scan'208";a="210214822" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2021 07:28:55 -0700 X-IronPort-AV: E=Sophos;i="5.84,236,1620716400"; d="scan'208";a="492912006" Received: from fhogg-mobl1.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.27.49]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 13 Jul 2021 07:28:51 -0700 Date: Tue, 13 Jul 2021 15:28:48 +0100 From: Bruce Richardson To: "Ananyev, Konstantin" Cc: Chengwen Feng , "thomas@monjalon.net" , "Yigit, Ferruh" , "jerinj@marvell.com" , "jerinjacobk@gmail.com" , "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" , "liangma@liangbit.com" Message-ID: References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1625995556-41473-1-git-send-email-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v2] 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 Tue, Jul 13, 2021 at 03:19:39PM +0100, Ananyev, Konstantin wrote: > > > +#include "rte_dmadev_core.h" > > + > > +/** > > + * DMA flags to augment operation preparation. > > + * Used as the 'flags' parameter of rte_dmadev_copy/copy_sg/fill/fill_sg. > > + */ > > +#define RTE_DMA_FLAG_FENCE (1ull << 0) > > +/**< DMA fence flag > > + * It means the operation with this flag must be processed only after all > > + * previous operations are completed. > > + * > > + * @see rte_dmadev_copy() > > + * @see rte_dmadev_copy_sg() > > + * @see rte_dmadev_fill() > > + * @see rte_dmadev_fill_sg() > > + */ > > + > > +/** > > + * @warning > > + * @b EXPERIMENTAL: this API may change without prior notice. > > + * > > + * Enqueue a copy operation onto the virtual DMA channel. > > + * > > + * This queues up a copy operation to be performed by hardware, but does not > > + * trigger hardware to begin that operation. > > + * > > + * @param dev_id > > + * The identifier of the device. > > + * @param vchan > > + * The identifier of virtual DMA channel. > > + * @param src > > + * The address of the source buffer. > > + * @param dst > > + * The address of the destination buffer. > > + * @param length > > + * The length of the data to be copied. > > + * @param flags > > + * An flags for this operation. > > + * > > + * @return > > + * - 0..UINT16_MAX: index of enqueued copy job. > > + * - <0: Error code returned by the driver copy function. > > + */ > > +__rte_experimental > > +static inline int > > +rte_dmadev_copy(uint16_t dev_id, uint16_t vchan, rte_iova_t src, rte_iova_t dst, > > + uint32_t length, uint64_t flags) > > +{ > > + struct rte_dmadev *dev = &rte_dmadevices[dev_id]; > > One question I have - did you guys consider hiding definitions of struct rte_dmadev > and rte_dmadevices[] into .c straight from the start? > Probably no point to repeat our famous ABI ethdev/cryptodev/... pitfalls here. > I considered it, but I found even moving one operation (the doorbell one) to be non-inline made a small but noticable perf drop. Until we get all the drivers done and more testing in various scenarios, I'd rather err on the side of getting the best performance.