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 23481A0C43; Wed, 16 Jun 2021 19:40:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D1ECF40683; Wed, 16 Jun 2021 19:40:43 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id BA5464067A for ; Wed, 16 Jun 2021 19:40:42 +0200 (CEST) IronPort-SDR: U6h7uH0QXJ0gtsPpxM0C/MuPoDJ0vxywMItr0wjdnYXsKOo6WXoWSao2VXsACz49hrkHbC4jKl 5v/pKX2lH4pw== X-IronPort-AV: E=McAfee;i="6200,9189,10016"; a="204396944" X-IronPort-AV: E=Sophos;i="5.83,278,1616482800"; d="scan'208";a="204396944" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2021 10:40:41 -0700 IronPort-SDR: 4VNYH7cwbVgBf7LYdW01RUXy7KBFNmBmCsfmt51Cj4VW94reyuVLfy2mqgar3cZg6/AyjZxS3g 0fh69zxTf+GQ== X-IronPort-AV: E=Sophos;i="5.83,278,1616482800"; d="scan'208";a="452428277" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.12.169]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Jun 2021 10:40:39 -0700 Date: Wed, 16 Jun 2021 18:40:35 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Jerin Jacob , Thomas Monjalon , dpdk-dev , Olivier Matz , Andrew Rybchenko , Honnappa Nagarahalli , "Ananyev, Konstantin" , Ferruh Yigit , Jerin Jacob , Akhil Goyal Message-ID: References: <20210614105839.3379790-1-thomas@monjalon.net> <2004320.XGyPsaEoyj@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61851@smartserver.smartshare.dk> <1857954.7Ex43hCf9S@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61862@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35C61864@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: <98CBD80474FA8B44BF855DF32C47DC35C61864@smartserver.smartshare.dk> Subject: Re: [dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays 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 Wed, Jun 16, 2021 at 05:01:46PM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Wednesday, 16 June 2021 15.03 > > > > On Wed, Jun 16, 2021 at 01:27:17PM +0200, Morten Brørup wrote: > > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > > > Sent: Wednesday, 16 June 2021 11.42 > > > > > > > > On Tue, Jun 15, 2021 at 12:18 PM Thomas Monjalon > > > > > > wrote: > > > > > > > > > > 14/06/2021 17:48, Morten Brørup: > > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas > > > > Monjalon > > > > > > It would be much simpler to just increase RTE_MAX_ETHPORTS to > > > > something big enough to hold a sufficiently large array. And > > possibly > > > > add an rte_max_ethports variable to indicate the number of > > populated > > > > entries in the array, for use when iterating over the array. > > > > > > > > > > > > Can we come up with another example than RTE_MAX_ETHPORTS where > > > > this library provides a better benefit? > > > > > > > > > > What is big enough? > > > > > Is 640KB enough for RAM? ;) > > > > > > > > If I understand it correctly, Linux process allocates 640KB due to > > > > that fact currently > > > > struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS] is global and > > it > > > > is from BSS. > > > > > > Correct. > > > > > > > If we make this from heap i.e use malloc() to allocate this memory > > > > then in my understanding Linux > > > > really won't allocate the real page for backend memory until > > unless, > > > > someone write/read to this memory. > > > > > > If the array is allocated from the heap, its members will be accessed > > though a pointer to the array, e.g. in rte_eth_rx/tx_burst(). This > > might affect performance, which is probably why the array is allocated > > the way it is. > > > > > > > It depends on whether the array contains pointers to malloced elements > > or > > the array itself is just a single malloced array of all the structures. > > While I think the parray proposal referred to the former - which would > > have > > an extra level of indirection - the switch we are discussing here is > > the > > latter which should have no performance difference, since the method of > > accessing the elements will be the same, only with the base address > > pointing to a different area of memory. > > I was not talking about an array of pointers. And it is not the same: > > int arr[27]; > int * parr = arr; > > // direct access > int dir(int i) { return arr[i]; } > > // indirect access > int indir(int i) { return parr[i]; } > > The direct access knows the address of arr, so it will compile to: > movsx rdi, edi > mov eax, DWORD PTR arr[0+rdi*4] > ret > > The indirect access needs to first read the memory location holding the pointer to the array, and then it can read the array member, so it will compile to: > mov rax, QWORD PTR parr[rip] > movsx rdi, edi > mov eax, DWORD PTR [rax+rdi*4] > ret > Interesting, thanks. Definitely seems like a bit of perf testing will be needed whatever way we go.