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 A8F9EA0C49; Wed, 16 Jun 2021 14:22:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 26E7D4067A; Wed, 16 Jun 2021 14:22:29 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 86BBF40140 for ; Wed, 16 Jun 2021 14:22:27 +0200 (CEST) IronPort-SDR: BVU2nLtRUYvQ/G3xSdCKG0ijHBwCzd3a6W27LxGLaG5aMBIl2jMv1Okm767MnzH2DITE4YwGb+ yxaEASELUbnw== X-IronPort-AV: E=McAfee;i="6200,9189,10016"; a="185856554" X-IronPort-AV: E=Sophos;i="5.83,277,1616482800"; d="scan'208";a="185856554" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2021 05:22:26 -0700 IronPort-SDR: kDAm31ahW21YSw+oIRiokKJwC8uQ94zsxjkOKpMQuT6mYEyZFI9RhLe3EwcKaw6/ZfDx8+0Kmv dszclTJpUuxQ== X-IronPort-AV: E=Sophos;i="5.83,277,1616482800"; d="scan'208";a="442865773" Received: from gepeat-mobl1.ger.corp.intel.com (HELO [10.213.218.158]) ([10.213.218.158]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2021 05:22:23 -0700 To: Jerin Jacob , Thomas Monjalon Cc: =?UTF-8?Q?Morten_Br=c3=b8rup?= , Bruce Richardson , dpdk-dev , Olivier Matz , Andrew Rybchenko , Honnappa Nagarahalli , "Ananyev, Konstantin" , Ferruh Yigit , Jerin Jacob , Akhil Goyal References: <20210614105839.3379790-1-thomas@monjalon.net> <2004320.XGyPsaEoyj@thomas> <98CBD80474FA8B44BF855DF32C47DC35C61851@smartserver.smartshare.dk> <1857954.7Ex43hCf9S@thomas> From: "Burakov, Anatoly" Message-ID: <01e1ade6-827f-83c7-5375-125b72888053@intel.com> Date: Wed, 16 Jun 2021 13:22:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 16-Jun-21 10:42 AM, Jerin Jacob wrote: > 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. > > 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. > > i.e it will be free virtual memory using Linux memory management help. > If so, we can keep large values for RTE_MAX_ETHPORTS > without wasting any "real" memory even though the system has a few ports. > > Thoughts? > mmap works this way with anonymous memory, i'm not so sure about malloc()'ed memory. Plus, we can't base these decisions on what Linux does because we support other OS's. Do they do this as well? -- Thanks, Anatoly