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 20951A0C47; Thu, 15 Jul 2021 10:29:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09D5541136; Thu, 15 Jul 2021 10:29:15 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 0DA094014D for ; Thu, 15 Jul 2021 10:29:13 +0200 (CEST) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4GQS7S13Dnz1CJg0; Thu, 15 Jul 2021 16:23:32 +0800 (CST) Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 15 Jul 2021 16:29:11 +0800 Received: from [10.40.190.165] (10.40.190.165) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 15 Jul 2021 16:29:10 +0800 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" References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <1626179263-14645-1-git-send-email-fengchengwen@huawei.com> From: fengchengwen Message-ID: <04d6b19d-ba8e-7c12-b76c-d7e8c7e0a923@huawei.com> Date: Thu, 15 Jul 2021 16:29:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.40.190.165] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected 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 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? > >> + struct rte_dmadev_port_parameters src_port; >> + /** 1) Used to describes the port parameter in the memory-to-device-to >> + * transfer scenario. >> + * 2) Used to describes the destination port parameter in the >> + * device-to-device transfer scenario. >> + * @see struct rte_dmadev_port_parameters >> + */ >> + struct rte_dmadev_port_parameters dst_port; >> +}; >> + > > > >> +/** >> + * @warning >> + * @b EXPERIMENTAL: this API may change without prior notice. >> + * >> + * Enqueue a scatter list copy operation onto the virtual DMA channel. >> + * >> + * This queues up a scatter list copy operation to be performed by hardware, >> + * but does not trigger hardware to begin that operation. > > This would need update with the submit flag. > The statement should be true only when the flag is set? > Similar comment I see on 'rte_dmadev_copy_sg' and 'rte_dma_fill' APIs OK, will fix in V4 > >> + * >> + * @param dev_id >> + * The identifier of the device. >> + * @param vchan >> + * The identifier of virtual DMA channel. >> + * @param sg >> + * The pointer of scatterlist. >> + * @param flags >> + * An flags for this operation. >> + * @see RTE_DMA_OP_FLAG_* >> + * >> + * @return >> + * - 0..UINT16_MAX: index of enqueued copy scatterlist job. >> + * - <0: Error code returned by the driver copy scatterlist function. >> + */ >> +__rte_experimental >> +static inline int >> +rte_dmadev_copy_sg(uint16_t dev_id, uint16_t vchan, const struct rte_dma_sg >> *sg, >> + uint64_t flags) >> +{ >> + struct rte_dmadev *dev = &rte_dmadevices[dev_id]; >> +#ifdef RTE_DMADEV_DEBUG >> + if (!rte_dmadev_is_valid_dev(dev_id) || >> + vchan >= dev->data->dev_conf.max_vchans || >> + sg == NULL) >> + return -EINVAL; >> + RTE_FUNC_PTR_OR_ERR_RET(*dev->copy_sg, -ENOTSUP); >> +#endif >> + return (*dev->copy_sg)(dev, vchan, sg, flags); >> +} >> + > > . >