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 1507D459C8; Wed, 18 Sep 2024 12:12:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8D09E402BA; Wed, 18 Sep 2024 12:12:26 +0200 (CEST) Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by mails.dpdk.org (Postfix) with ESMTP id 62AFB4025C for ; Wed, 18 Sep 2024 12:12:25 +0200 (CEST) Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6c34c2a7dc7so41261256d6.3 for ; Wed, 18 Sep 2024 03:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726654345; x=1727259145; 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=/QwRBPrCJwq3Q2e3TDjXV6JgnlwCoelUZni/WlxCHEg=; b=ZSiQ9/mrDZfsPW6AGzqrDMcIDcUIn9ixyp5CtFEaggdMpppviSmkbayrsSfGi1NKp5 Fo2q5+1oOLArLnxg6ZU5rcCw+2FS5qxbaNjYLjXTg7hIvGqhXyJO9hAX3+SRJfFtQXg/ yqJfISOvQwJDv1/iLj4Hq3FA0J4/puj6DRACufq2CDTtfxGvK5sTzdCcAahQItpVTRIX KsUYSkqMfMFkTH4tekiqqXx1OGn60sex4jiqs85JCT9LZPAtSxDWqDl7LIoFNTI1Ec1h ToXLJP3q11dzeEnjsrUAxdgXF9S+mvmlH80C+C2wsAHqKYCGL8JhIfnzQzGfsGYZPk3p T8/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726654345; x=1727259145; 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=/QwRBPrCJwq3Q2e3TDjXV6JgnlwCoelUZni/WlxCHEg=; b=C3O8SQnqvR45eDy/f9KO2f17adfRI0t5NjRefqoKu57cRF3by3EYEv5LpV9KVA9FlF 64LZvKZSVCUt2tKZT4HylJuQS+/oS2p0ucCtEMtDKA0XJVbUQJ9wZvygR5Q6wU06dcUz mB5qlpMZDvv+mlZTWqSH7yg0b2AJ703eKoCCh45pt0eQP0Nvl1WzyCkiNQQh94obxH33 ohDWaa8Bzl/JWWSHCV8vzjSxL0hXuRZTVKzF4iubqiDHDwfOFGb9+H7hT2MaSbyr0plW RAQgXwGcq6MGce+k4kvwhr0QEk7YzrDLYu/Jx0iMed5JjTsfK0VD4ERNBrdW3ivrMgPI b35A== X-Forwarded-Encrypted: i=1; AJvYcCVsObNXmaot31fmnum2j7/QoOdVE70G4EwW6iwTopUjwDh34gOqqc2yCFcfesRiY9GGtpM=@dpdk.org X-Gm-Message-State: AOJu0YxGpqm77KaTSiNr/wnA1leArE6SRWClWAFy1F+uXgS1KrQmv4HK UMvVlX4GdhOGftA+qNFapLRLejroWD3/nLTheIXY7eay5u8Js+kG363YAsvJ28P+zax8IjQw35w zqsGJGTy5yjoqKRU1HqEQOca4cVc= X-Google-Smtp-Source: AGHT+IEZ08it0+iL1aPgZ1HE2oTMtFLGo2YFrUyLAcZoQpTOjOyrCw5v5gqzZqbZAnPRut6AGymBGH3/X3s3P1RHHFQ= X-Received: by 2002:a05:6214:451c:b0:6c5:5114:96e8 with SMTP id 6a1803df08f44-6c57353515fmr303778156d6.21.1726654344653; Wed, 18 Sep 2024 03:12:24 -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: From: Jerin Jacob Date: Wed, 18 Sep 2024 15:41:58 +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 8:52=E2=80=AFPM Jerin Jacob = wrote: > > 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 var= iables. > > > > > > > > And lcore variables are not usable (shared) for DPDK multi-process,= so the > > > lcore_buffer could be allocated through the O/S APIs as anonymous hug= epages, > > > instead of using rte_malloc(). > > > > > > > > The alternative, using rte_malloc(), would disallow allocating lcor= e > > > 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 th= e > > > 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= useful. > > > > Yes, it would be good to replace (or supplement) RTE_INIT_PRIO by somet= hing similar, which calls the list of "INIT" functions at the appropriate t= ime during EAL initialization. > > > > DPDK should then use this "INIT" list for all its initialization, so th= e init function of new features (such as this, and trace) can be inserted a= t 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 altern= ative is to prohibit establishing lcore variables in functions called throu= gh 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. @Mattias R=C3=B6nnblom This comment is not addressed in v7. Could you check= ?