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 9D7DEA0A0F; Mon, 5 Jul 2021 13:12:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 616E14068C; Mon, 5 Jul 2021 13:12:58 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id DF3984003C for ; Mon, 5 Jul 2021 13:12:56 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Jul 2021 13:12:54 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C618E4@smartserver.smartshare.dk> In-Reply-To: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH] dmadev: introduce DMA device library Thread-Index: Addxi+jJARLRwLHET+K5LMQJ1+iIggAARuGQ References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "Jerin Jacob" Cc: "Chengwen Feng" , "Thomas Monjalon" , "Ferruh Yigit" , "Jerin Jacob" , "dpdk-dev" , "Nipun Gupta" , "Hemant Agrawal" , "Maxime Coquelin" , "Honnappa Nagarahalli" , "David Marchand" , "Satananda Burla" , "Prasun Kapoor" , "Ananyev, Konstantin" , , "Radha Mohan Chintakuntla" Subject: Re: [dpdk-dev] [PATCH] 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" > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Monday, 5 July 2021 12.53 >=20 > On Sun, Jul 04, 2021 at 03:00:30PM +0530, Jerin Jacob wrote: > > On Fri, Jul 2, 2021 at 6:51 PM Chengwen Feng > wrote: > > > > > > + > > > +/** > > > + * The data structure associated with each DMA device. > > > + */ > > > +struct rte_dmadev { > > > + /**< Enqueue a copy operation onto the DMA device. */ > > > + dmadev_copy_t copy; > > > + /**< Enqueue a scatter list copy operation onto the DMA > device. */ > > > + dmadev_copy_sg_t copy_sg; > > > + /**< Enqueue a fill operation onto the DMA device. */ > > > + dmadev_fill_t fill; > > > + /**< Enqueue a scatter list fill operation onto the DMA > device. */ > > > + dmadev_fill_sg_t fill_sg; > > > + /**< Add a fence to force ordering between operations. */ > > > + dmadev_fence_t fence; > > > + /**< Trigger hardware to begin performing enqueued > operations. */ > > > + dmadev_perform_t perform; > > > + /**< Returns the number of operations that successful > completed. */ > > > + dmadev_completed_t completed; > > > + /**< Returns the number of operations that failed to > complete. */ > > > + dmadev_completed_fails_t completed_fails; > > > > We need to limit fastpath items in 1 CL > > >=20 > I don't think that is going to be possible. I also would like to see > numbers to check if we benefit much from having these fastpath ops > separate > from the regular ops. The fastpath ops may not fit into 1 cache line, but it is a good design = practice to separate hot data from cold data, and I do consider the = fastpath function pointers hot and configuration function pointers cold. The important point is keeping all the fastpath ops (of a dmadevice) = together and spanning as few cache lines as possible. Configuration ops and other slow data may follow in the same structure; = that should make no performance difference. It might make a difference = for memory consumption if the other data are very large and not = dynamically allocated, as we are discussing regarding ethdev.