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 297AFA0C49; Tue, 15 Jun 2021 10:45:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0F2D54067A; Tue, 15 Jun 2021 10:45:00 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id B58D040140 for ; Tue, 15 Jun 2021 10:44:57 +0200 (CEST) IronPort-SDR: tfTXY9dnWnr12RIW3fKgyAtPWKD45AFgflxwU/U839Xtxu2Mlk7qJQlB2Rbgzu4UWTJv8SHFMf 7NDYZ/fscWKA== X-IronPort-AV: E=McAfee;i="6200,9189,10015"; a="227414523" X-IronPort-AV: E=Sophos;i="5.83,275,1616482800"; d="scan'208";a="227414523" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jun 2021 01:44:56 -0700 IronPort-SDR: J+/xpNHUspXMCGvFEYp70iCJiibsXLHPcp7dihrsWWgGIikdIC4RycOYp5282p2NzXxNaW2G6w SeCTAIgW3PZA== X-IronPort-AV: E=Sophos;i="5.83,275,1616482800"; d="scan'208";a="484391718" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.31.246]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Jun 2021 01:44:53 -0700 Date: Tue, 15 Jun 2021 09:44:45 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Thomas Monjalon , dev@dpdk.org, olivier.matz@6wind.com, andrew.rybchenko@oktetlabs.ru, honnappa.nagarahalli@arm.com, konstantin.ananyev@intel.com, ferruh.yigit@intel.com, jerinj@marvell.com, gakhil@marvell.com Message-ID: References: <20210614105839.3379790-1-thomas@monjalon.net> <2004320.XGyPsaEoyj@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61851@smartserver.smartshare.dk> <1857954.7Ex43hCf9S@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61855@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: <98CBD80474FA8B44BF855DF32C47DC35C61855@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 Tue, Jun 15, 2021 at 09:53:33AM +0200, Morten Brørup wrote: > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Tuesday, 15 June 2021 08.48 > > > > 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? ;) > > Good point! > > I think we agree that: > - The cost of this library is some added complexity, i.e. working with a dynamically sized array through a library instead of just indexing into a compile time fixed size array. > - The main benefit of this library is saving some RAM (and still allowing a potentially very high number of ports.) > > My point was: The amount of RAM we are saving is a key parameter for the cost/benefit analysis. And since I don't think the rte_eth_devices[] array uses a significant amount of memory, I was asking for some other array using more memory, where the cost/benefit analysis would come out more advantageous to your proposed parray library. > > > > > When dealing with microservices switching, the numbers can increase > > very fast. > > Yes, I strongly supported increasing the port_id type from 8 to 16 bits for this reason, when it was discussed at the DPDK Userspace a few years ago in Dublin. And with large RTE_MAX_QUEUES_PER_PORT values, the rte_eth_dev structure uses quite a lot of space for the rx/tx callback arrays. But the memory usage of rte_eth_devices[] is still relatively insignificant in a system wide context. > > If main purpose is to optimize the rte_eth_devices[] array, I think there are better alternatives than this library. Bruce and Konstantin already threw a few ideas on the table. > Yes, though I think we need to be clear on what problems we are trying to solve here. A generic resizable array may be a useful library for DPDK in its own right, but for the ethdev (and other devs) arrays I think my understanding of the problem is that we want: * scalability of ethdevs list to large numbers of ports, e.g. 2k * while not paying a large memory footprint penalty for those apps which only need a small number of ports, e.g. 2 or 4. Is that a fair summary? /Bruce`