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 162084596F; Thu, 12 Sep 2024 17:22:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 85CFB402EE; Thu, 12 Sep 2024 17:22:36 +0200 (CEST) Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by mails.dpdk.org (Postfix) with ESMTP id 9E7E44028F for ; Thu, 12 Sep 2024 17:22:35 +0200 (CEST) Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e1a819488e3so1083826276.3 for ; Thu, 12 Sep 2024 08:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726154555; x=1726759355; 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=XOO/48tq4X8w357Rpfsyn6BDGnVVWBAqOWXZP9ipamM=; b=ne98BB6WRDqWVdKh2uWljlOwYQ6Kw6CmNSxz4okR7rF6LI7WPxrUdaSK03mjf5IpNy E2gPwFgJiBGAYB1js+9HoA9MpOpcSRirbBDeCRZ1+u9donmQtleOR/xfhZPgfAadzOuG WXFaUX3Hly+QG74owx2xeIeK2uk6pOPIeYaVYVwA2XN9WvYEjckz8zOuRougibapH+r8 AABD8+QNqthu7X2HF5GhB6wbNWZqWV2U/Ff6y1ACfS54Gpv+id1PoFkOdwQAxSRXuNKq VSQVFPD9g6kuDT9pjlB3WO0kU4H92oajlzdTLe7iAItdJlPRYNucMtfWd/hrkdQbHJOo JBKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726154555; x=1726759355; 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=XOO/48tq4X8w357Rpfsyn6BDGnVVWBAqOWXZP9ipamM=; b=mYviap/Gm7m9rSginA0j2NWgQTMUWN9itdV8/cRdM0kmetMRvvB2IIBHFWeQjHli0O cZFMTA9AfphtQi3lAtfTddpQtKMiH1AXapW2Jcum0mGGCfNFJ20BvDMvmKYlRta1XIF0 QbZFrStBXX9ayvAuDDmofJMHfRH9F0TLy7XHUC7lANE/uaBpLkkBbTewUUiGWnh68LnA xGqTP4Xatkm645/v5zTG5G3HT1JhgQBT/ShoZK9wbwXpgXk3EuiHvHuQnMxjPdWFPtln UMW++LhsKBrQwOVFcLXQ65nPXwv2e0IdJYFA5Sv2GqlSA5j+QntI/3LI/APd3hiZAZyq DOcg== X-Forwarded-Encrypted: i=1; AJvYcCV7VZJCYqoJP8q3VJzB+fKOkl+MZIbFtZCyey4tWUucBgqQtSvmnkodlhMYDE5pYCKaJww=@dpdk.org X-Gm-Message-State: AOJu0YwPqqGcEr0wBKGhH6QMqFzl3pk9AlrcpNUOKziuNHUTbnYWeisG y9UPhnxwHwlKpmDqZB2nAtpfFNpejahMcrmJSNEwbrUcWQ02bl+GYED4JwJ2XbrYHsOw/KKLkzX hfzKUtclK0idjG8cJk9pagxIASc/rxoqU X-Google-Smtp-Source: AGHT+IHruotnB0x8gBp2/SFqaL3+ii+5G0gIquEsZKc/qHeas2C8Sodr8OD5sCh45d65Sm8I1WGq9URy140avoU+db0= X-Received: by 2002:a05:6902:1603:b0:e16:6aae:e65 with SMTP id 3f1490d57ef6-e1d9dba6dafmr3004786276.13.1726154554872; Thu, 12 Sep 2024 08:22:34 -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> <98CBD80474FA8B44BF855DF32C47DC35E9F6DB@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F6DB@smartserver.smartshare.dk> From: Jerin Jacob Date: Thu, 12 Sep 2024 20:52:07 +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 7:11=E2=80=AFPM Morten Br=C3=B8rup wrote: > > > From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > Sent: Thursday, 12 September 2024 15.17 > > > > 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_malloc()) is ready, so rte_malloc() cannot be used for lcore varia= bles. > > > > > > And lcore variables are not usable (shared) for DPDK multi-process, s= o the > > lcore_buffer could be allocated through the O/S APIs as anonymous hugep= ages, > > instead of using rte_malloc(). > > > > > > The alternative, using rte_malloc(), would disallow allocating lcore > > variables 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) > > The list of RTE_INIT functions are called before main(). It is not very u= seful. > > Yes, it would be good to replace (or supplement) RTE_INIT_PRIO by somethi= ng similar, which calls the list of "INIT" functions at the appropriate tim= e during EAL initialization. > > DPDK should then use this "INIT" list for all its initialization, so the = init function of new features (such as this, and trace) can be inserted at = the correct location in the list. > > > Trace library had a similar situation. It is managed like [2] > > Yes, if we insist on using rte_malloc() for lcore variables, the alternat= ive is to prohibit establishing lcore variables in functions called through= RTE_INIT. I was not insisting on using ONLY rte_malloc(). Since rte_malloc() can be called before rte_eal_init)(it will return NULL). Alloc routine can check first rte_malloc() is available if not switch over glibc.