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 16B3BA0C49; Tue, 15 Jun 2021 09:53:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 955C64067A; Tue, 15 Jun 2021 09:53:36 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 3D5B040140 for ; Tue, 15 Jun 2021 09:53:35 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2021 09:53:33 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C61855@smartserver.smartshare.dk> In-Reply-To: <1857954.7Ex43hCf9S@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays Thread-Index: AddhsnAgmk8b5J9KRF6HAQDNvc3wXgAAfn3A References: <20210614105839.3379790-1-thomas@monjalon.net> <2004320.XGyPsaEoyj@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61851@smartserver.smartshare.dk> <1857954.7Ex43hCf9S@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" Cc: "Bruce Richardson" , , , , , , , , 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" > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, 15 June 2021 08.48 >=20 > 14/06/2021 17:48, Morten Br=F8rup: > > > 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? >=20 > 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. >=20 > 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.