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 32A1BA0A0F; Mon, 5 Jul 2021 15:44:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A51A240040; Mon, 5 Jul 2021 15:44:41 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 071614003C for ; Mon, 5 Jul 2021 15:44:39 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10035"; a="230704530" X-IronPort-AV: E=Sophos;i="5.83,325,1616482800"; d="scan'208";a="230704530" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jul 2021 06:44:37 -0700 X-IronPort-AV: E=Sophos;i="5.83,325,1616482800"; d="scan'208";a="496128816" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.23.142]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 05 Jul 2021 06:44:21 -0700 Date: Mon, 5 Jul 2021 14:44:18 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Jerin Jacob , 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" , liangma@liangbit.com, Radha Mohan Chintakuntla Message-ID: References: <1625231891-2963-1-git-send-email-fengchengwen@huawei.com> <98CBD80474FA8B44BF855DF32C47DC35C618E4@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C618E4@smartserver.smartshare.dk> 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" On Mon, Jul 05, 2021 at 01:12:54PM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Monday, 5 July 2021 12.53 > > > > 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 > > > > > > > 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. > Yes, I agree if it can be done, it should be.