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 8031F4596E; Thu, 12 Sep 2024 15:17:25 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6EED040265; Thu, 12 Sep 2024 15:17:25 +0200 (CEST) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by mails.dpdk.org (Postfix) with ESMTP id EEC8640144 for ; Thu, 12 Sep 2024 15:17:23 +0200 (CEST) Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-4582760b79cso4507821cf.2 for ; Thu, 12 Sep 2024 06:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726147043; x=1726751843; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=J4RyVbP4JFyrwxpyzv6RGgO84Wf0BSkaS4ywDySjyuc=; b=RdtqsnLnPtfpXTVFv/pfcEoHnsw2wXofnSP/odafBGLPbKKvNU592epLcdU3TUHMi+ YVt2jvR092MAsk6fxUq5ZQPKRYREWDSoRr2QRd54OMpu0/cDVhEWHlBIc4jVzA8WwVNL YNNHOFpg/UZJKUr6U03PholExWkqaA9xZtEFLnYHGjDLcL/Uf1Cg97VdXftgfor20xnm 6Bo1JzVvHtJLjr3ijct5K9ir07CWrJzR2l57KVY966tX57apDu4oADd7DchuCDlId/E0 ED74deyOUo+cE7Q7nuRR7U0vhM9ZcOsCQrf0tE+dt4MK8cvJJ+KrnJOh5BkxoKsMO0L/ TGsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726147043; x=1726751843; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J4RyVbP4JFyrwxpyzv6RGgO84Wf0BSkaS4ywDySjyuc=; b=cPM2J730VSLyQIe8Fn0ehBjsVdbapwh/490ePNsni5urSL3BuLHNHZ5U0XU/y/Hlva IOAwcRC6EdIBas608Rgk9VKSoVP8WfP3IK66QOJr4wbgaRfChL7miOKfhnCtb5x0NMUq XTws47C7mx7fY89UUtEY/Kw5TMeSm2VcZVEt8V9hqq6nPiwPEyz+KM7dlNkEEu/zXi2u vgiQwJ1HkIKuBPsk8l0CtUiEw9qjyKWnp/0RmsE3lfiC6/k4ApN/wWi3ggNN0vHXu3fQ UEkNU+2JVxaSIy+mLzhjJ3+l5P51EnMmkjE0zT91g8UWLaPh6qXEzF6Wqil6LBGM1zoh e82Q== X-Forwarded-Encrypted: i=1; AJvYcCWZqrayd5HwKt+BqiNRHpRgvETE3vQfQypKW8cTtrVddimmzoUiJkVIheBYPNy5K53tRrg=@dpdk.org X-Gm-Message-State: AOJu0YwkfaxyJcJqjDFdNFxRx9YVLn6RNOp5gffJJdBHN8HJbu1Oqm0T JZjUzcYqao1nz/fpZYDHaLHysa9wnb7KDlr+I4356hMFM4pwR58eSKjaXWeHTCaqx9pxqVKApw+ rNvLq6v20Tog/uNhkN5UGksbFtv8= X-Google-Smtp-Source: AGHT+IEaEVSTF4oS1pmgIeu70NBUn7SMCKDphTVNju/PusZ/SPKaLYO9QBp2d0gBBODdTHqJTfQZbfQV7GxZ49ZGt30= X-Received: by 2002:a05:622a:3c6:b0:458:3d2c:27ee with SMTP id d75a77b69052e-4586029c508mr33441141cf.2.1726147043215; Thu, 12 Sep 2024 06:17:23 -0700 (PDT) MIME-Version: 1.0 References: <20240910070344.699183-2-mattias.ronnblom@ericsson.com> <20240911170430.701685-1-mattias.ronnblom@ericsson.com> <20240911170430.701685-2-mattias.ronnblom@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35E9F6D3@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6D3@smartserver.smartshare.dk> From: Jerin Jacob Date: Thu, 12 Sep 2024 18:46:57 +0530 Message-ID: Subject: Re: [PATCH v2 1/6] eal: add static per-lcore memory allocation facility To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org, Chengwen Feng , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Stephen Hemminger , Konstantin Ananyev , David Marchand , Anatoly Burakov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Thu, Sep 12, 2024 at 2:40=E2=80=AFPM Morten Br=C3=B8rup wrote: > > > +#define LCORE_BUFFER_SIZE (RTE_MAX_LCORE_VAR * RTE_MAX_LCORE) > > Considering hugepages... > > Lcore variables may be allocated before DPDK's memory allocator (rte_mall= oc()) is ready, so rte_malloc() cannot be used for lcore variables. > > And lcore variables are not usable (shared) for DPDK multi-process, so th= e lcore_buffer could be allocated through the O/S APIs as anonymous hugepag= es, instead of using rte_malloc(). > > The alternative, using rte_malloc(), would disallow allocating lcore vari= ables before DPDK's memory allocator has been initialized, which I think is= too late. I thought it is not. A lot of the subsystems are initialized after the memory subsystem is initialized. [1] example given in documentation. I thought, RTE_INIT needs to replaced if the subsystem called after memory initialized (which is the case for most of the libraries) Trace library had a similar situation. It is managed like [2] [1] * struct foo_lcore_state { * int a; * long b; * }; * * static RTE_LCORE_VAR_HANDLE(struct foo_lcore_state, lcore_states); * * long foo_get_a_plus_b(void) * { * struct foo_lcore_state *state =3D RTE_LCORE_VAR_VALUE(lcore_stat= es); * * return state->a + state->b; * } * * RTE_INIT(rte_foo_init) * { * RTE_LCORE_VAR_ALLOC(lcore_states); * * struct foo_lcore_state *state; * RTE_LCORE_VAR_FOREACH_VALUE(state, lcore_states) { * (initialize 'state') * } * * (other initialization) * } [2] /* First attempt from huge page */ header =3D eal_malloc_no_trace(NULL, trace_mem_sz(trace->buff_len),= 8); if (header) { trace->lcore_meta[count].area =3D TRACE_AREA_HUGEPAGE; goto found; } /* Second attempt from heap */ header =3D malloc(trace_mem_sz(trace->buff_len)); if (header =3D=3D NULL) { trace_crit("trace mem malloc attempt failed"); header =3D NULL; goto fail; }