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 A0FF2A0C49; Tue, 15 Jun 2021 11:28:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2887D4067A; Tue, 15 Jun 2021 11:28:23 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 6C0AE40140 for ; Tue, 15 Jun 2021 11:28:21 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id F0A84580795; Tue, 15 Jun 2021 05:28:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 15 Jun 2021 05:28:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= UUbeWByqkRhuRY1MHXKrzpmSq7HV4MpqKnTuJnnC44g=; b=6BomsbyUPmEy7KJ4 F/vxuxqscjyQrpYiARCb3r4ku+gmX58L3hKx5vvMgcF4utu5d5qbJZWbRPrqESBO ddRftYN1jNwdT8FgbxCSPlKd9UxxnzMILIMUmjFrzK8uv0z66bw0z9Jtd4sIlQZv 9CJT03YHHge80Y7C4G0S3Cf5DJC4uwTUAEE8QJCHtTLIgThp9cI3iB4EoiDepLlI FMI4V2LUW/Rpo/mGG9FgOI5jvsvO7VGS1UmSvDJLc0eYJtt/iosYj4gGAHKtovgw NALVe9tFtrOZASWbqmE+fEQIjXgLHd16DdXLjna4mSEziUHxLF+bnOe9cNWQembu aZ+Buw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UUbeWByqkRhuRY1MHXKrzpmSq7HV4MpqKnTuJnnC4 4g=; b=ufg95y/4zW8cKB8wYl8DOWyuR8bAPlQbVXbwku/2TwiQZ/ODi2aIpEha2 Uxeegn9aff92gcUUd64KH54xOhCRqI0gJteQ7UU5R61dcSVZLA/S2xH+S+i+9Mvw hBtwFZe0dLyUj3USDEUD5xkYpv1HOfQ5FRMA+0dsh1O0xWV6T8tCK5Afu0XNcwb+ cavxDls1pbNQBZJaM9TBSkWAcq02aRPqIItu3Wo4mlqE+HvpM4KxscopH6CrbXGW 3EyhdfdGC5u13gCn4IRHBen2khl77kYQLM8kFTIVLUzNVlf7eRQgsWZMy3Cokf8M Rg0FVBapvozOFgWGdgcbTCgAiASHA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvjedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepfeegffeihfeftedthfdvgfetkeffffdukeevtdevtddvgfevuedu veegvdeggedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Jun 2021 05:28:18 -0400 (EDT) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= , Bruce Richardson Cc: 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, david.marchand@redhat.com Date: Tue, 15 Jun 2021 11:28:16 +0200 Message-ID: <3350188.y60jeB2voQ@thomas> In-Reply-To: References: <20210614105839.3379790-1-thomas@monjalon.net> <98CBD80474FA8B44BF855DF32C47DC35C61855@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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" 15/06/2021 10:44, Bruce Richardson: > On Tue, Jun 15, 2021 at 09:53:33AM +0200, Morten Br=F8rup wrote: > > > 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? ;) > >=20 > > Good point! > >=20 > > 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 allowi= ng a potentially very high number of ports.) > >=20 > > My point was: The amount of RAM we are saving is a key parameter for th= e cost/benefit analysis. And since I don't think the rte_eth_devices[] arra= y uses a significant amount of memory, I was asking for some other array us= ing more memory, where the cost/benefit analysis would come out more advant= ageous to your proposed parray library. > >=20 > > >=20 > > > When dealing with microservices switching, the numbers can increase > > > very fast. > >=20 > > 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 a= go in Dublin. And with large RTE_MAX_QUEUES_PER_PORT values, the rte_eth_de= v structure uses quite a lot of space for the rx/tx callback arrays. But th= e memory usage of rte_eth_devices[] is still relatively insignificant in a = system wide context. > >=20 > > If main purpose is to optimize the rte_eth_devices[] array, I think the= re are better alternatives than this library. Bruce and Konstantin already = threw a few ideas on the table. > > >=20 > 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: >=20 > * 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. >=20 > Is that a fair summary? Yes. We must take into account two related issues: - the app and libs could allocate some data per device, increasing the bill. - per-device allocation may be more efficient if allocated on the NUMA node of the device