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 6F2BAA0C41; Thu, 15 Jul 2021 14:11:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D14E54014D; Thu, 15 Jul 2021 14:11:56 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 55C1540143 for ; Thu, 15 Jul 2021 14:11:55 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10045"; a="197797400" X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="197797400" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2021 05:11:54 -0700 X-IronPort-AV: E=Sophos;i="5.84,240,1620716400"; d="scan'208";a="495408968" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.5.22]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Jul 2021 05:11:50 -0700 Date: Thu, 15 Jul 2021 13:11:46 +0100 From: Bruce Richardson To: Nipun Gupta Cc: fengchengwen , "thomas@monjalon.net" , "ferruh.yigit@intel.com" , "jerinj@marvell.com" , "jerinjacobk@gmail.com" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" , "mb@smartsharesystems.com" , Hemant Agrawal , "maxime.coquelin@redhat.com" , "honnappa.nagarahalli@arm.com" , "david.marchand@redhat.com" , "sburla@marvell.com" , "pkapoor@marvell.com" , "konstantin.ananyev@intel.com" , Gagandeep Singh Message-ID: References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1626179263-14645-1-git-send-email-fengchengwen@huawei.com> <04d6b19d-ba8e-7c12-b76c-d7e8c7e0a923@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v3] 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 15, 2021 at 11:16:54AM +0000, Nipun Gupta wrote: > > > > -----Original Message----- > > From: fengchengwen > > Sent: Thursday, July 15, 2021 1:59 PM > > To: Nipun Gupta ; thomas@monjalon.net; > > ferruh.yigit@intel.com; bruce.richardson@intel.com; jerinj@marvell.com; > > jerinjacobk@gmail.com; andrew.rybchenko@oktetlabs.ru > > Cc: dev@dpdk.org; mb@smartsharesystems.com; Hemant Agrawal > > ; maxime.coquelin@redhat.com; > > honnappa.nagarahalli@arm.com; david.marchand@redhat.com; > > sburla@marvell.com; pkapoor@marvell.com; konstantin.ananyev@intel.com; > > Gagandeep Singh > > Subject: Re: [PATCH v3] dmadev: introduce DMA device library > > > > On 2021/7/14 20:22, Nipun Gupta wrote: > > > > > > > > >> +/** > > >> + * A structure used to configure a virtual DMA channel. > > >> + */ > > >> +struct rte_dmadev_vchan_conf { > > >> + uint8_t direction; > > >> + /**< Set of supported transfer directions > > >> + * @see RTE_DMA_MEM_TO_MEM > > >> + * @see RTE_DMA_MEM_TO_DEV > > >> + * @see RTE_DMA_DEV_TO_MEM > > >> + * @see RTE_DMA_DEV_TO_DEV > > >> + */ > > >> + /** Number of descriptor for the virtual DMA channel */ > > >> + uint16_t nb_desc; > > >> + /** 1) Used to describes the port parameter in the device-to-memory > > >> + * transfer scenario. > > >> + * 2) Used to describes the source port parameter in the > > >> + * device-to-device transfer scenario. > > >> + * @see struct rte_dmadev_port_parameters > > >> + */ > > > > > > There should also be a configuration to support no response (per Virtual > > Channel), > > > And if that is enabled, user will not be required to call 'rte_dmadev_completed' > > API. > > > This shall also be part of capability. > > > > Do you mean some silent mode? The application only needs to submit requests > > to the > > hardware. > > > > Could you briefly describe the working principles and application scenarios of > > the > > corresponding device? > > It is kind of a silent mode w.r.t. the command completion from QDMA. > > There could be level of synchronization in the applications at a higher level due > To which QDMA status dequeue would not be necessary and be an overhead. > In this mode extra data/bytes could be passed with DMA which would indirectly > indicate if DMA is complete or not. > I'm wondering if such a setting could be per-device (i.e. per HW queue) rather than per virtual channel? Something like this would be easier to support in that way, because we could use different function pointers for the fastpath operations depending on whether completions are to be tracked or not. For example: only occasional descriptors will need completion addresses specified in the "enqueue" calls, and the "submit" function would also do any ring cleanup that would otherwise be done by "completed" call. Having separate function calls would reduce the number of branches that need to be evaluated in this mode, as well as simplifying the code. /Bruce