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 EAE67A0C40; Sat, 12 Jun 2021 10:31:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6BB5B4003F; Sat, 12 Jun 2021 10:31:40 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 465194003E for ; Sat, 12 Jun 2021 10:31:39 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 899FA5C0037; Sat, 12 Jun 2021 04:31:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 12 Jun 2021 04:31:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= Kk97wZRWEdVm6WNUYsVBhKWhMFrJxuw8jvv0W7KlblE=; b=apPY2dJu+QoiIOvK kLxKtkGpfMKgIz95ZLmxdksHfVnGBtav/GNGGt54JaGvFJ03yyBW1JpCZN/H66vo fDdSXN/krKcHBtDpVoBj7V2eBjGrQKUnmI4zv9PGAm5Y5oY0ZEkBa9+EFmcagQ/8 /ZC6D1n2hDPGm/qil7CgXXArUzZOBGPzW9ge0cLd+b2I2r1IL9yTr+26tvcHHP0L gEsaLBbIGqqJRh+cD/GiMk0pRktmMLoLUobu5B+s8juTzjU2iBQlC8gHaiKpqin0 36v/oWP8ALN2wAi6e/D+NaDwqZ5dudlQxLvd3Di4lJdfR/pkbuOSBxaCvKlf3LCO 582p8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Kk97wZRWEdVm6WNUYsVBhKWhMFrJxuw8jvv0W7Klb lE=; b=C9+M1LwjnBiY+zIAuuHBIDmdDJ3qdvjMWwMpZCH3VbT5yTLcNWPtMr12Y 8JeN7FkNGpT/My2jsRrG7E+CltMvqKVxhyE9tZzuAOR7pd1dtLSZ2rlsJQH8gVtf G/0kE6oUKS8QD622AnzXlca4QLUFErxuDHNCMDhAnhAT5ivOuG8Gq5xd0/Q8aXNJ B3V57Tmb3XydqkQCasBlUCKQ5dQIqXubzqzuesUR7OgI/+qHysqx89clE4Nytn8Q q86rTCUvkk5BC8riPYIntnFtZwppHOQrs+Gy+oNU7R6T3Ukg+FH9Drq3qwQuC8gc K3u3VK+bAsqZctedBNrisyWBBrp8g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvtddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 12 Jun 2021 04:31:35 -0400 (EDT) From: Thomas Monjalon To: fengchengwen Cc: Ferruh Yigit , "dev@dpdk.org" , nipun.gupta@nxp.com, hemant.agrawal@nxp.com, "Richardson, Bruce" , maxime.coquelin@redhat.com, honnappa.nagarahalli@arm.com, jerinj@marvell.com, david.marchand@redhat.com Date: Sat, 12 Jun 2021 10:31:33 +0200 Message-ID: <7807476.CTUdPGCxKm@thomas> In-Reply-To: <27a77ca8-9406-1737-ff84-774b2ca561f7@huawei.com> References: <27a77ca8-9406-1737-ff84-774b2ca561f7@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] RFC: Kunpeng DMA driver API design decision 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" 12/06/2021 09:01, fengchengwen: > Hi all, > > We prepare support Kunpeng DMA engine under rawdev framework, and observed that > there are two different implementations of the data plane API: > 1. rte_rawdev_enqueue/dequeue_buffers which was implemented by dpaa2_qdma and > octeontx2_dma driver. > 2. rte_ioat_enqueue_xxx/rte_ioat_completed_ops which was implemented by ioat > driver. > > Due to following consideration (mainly performance), we plan to implement API > like ioat (not the same, have some differences) in data plane: > 1. The rte_rawdev_enqueue_buffers use opaque buffer reference which is vendor's > specific, so it needs first to translate application parameters to opaque > pointer, and then driver writes the opaque data onto hardware, this may lead > to performance problem. > 2. rte_rawdev_xxx doesn't provide memory barrier API which may need to extend > by opaque data (e.g. add flag to every request), this may introduce some > complexity. > > Also the example/ioat was used to compare DMA and CPU-memcopy performance, > Could we generalized it so that it supports multiple-vendor ? > > I don't know if the community accepts this kind of implementation, so if you > have any comments, please provide feedback. I would love having a common generic API. I would prefer having drivers under drivers/dma/ directory, rather than rawdev.