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 6D36C459C6; Wed, 18 Sep 2024 09:50:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A48942E8F; Wed, 18 Sep 2024 09:50:38 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 38A7642E8C for ; Wed, 18 Sep 2024 09:50:37 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D55881DA9D for ; Wed, 18 Sep 2024 09:50:36 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id C7C451DB83; Wed, 18 Sep 2024 09:50:36 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.2 Received: from [192.168.1.86] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 649371DB81; Wed, 18 Sep 2024 09:50:34 +0200 (CEST) Message-ID: <9a103a7d-3d7a-46e8-bf53-d657f55be358@lysator.liu.se> Date: Wed, 18 Sep 2024 09:50:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/7] eal: add static per-lcore memory allocation facility To: Konstantin Ananyev , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "dev@dpdk.org" Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob References: <20240912084429.703405-2-mattias.ronnblom@ericsson.com> <20240916105210.721315-1-mattias.ronnblom@ericsson.com> <20240916105210.721315-2-mattias.ronnblom@ericsson.com> <23d1b3c5828546128b9ed21e98ac1ae1@huawei.com> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2024-09-17 18:29, Konstantin Ananyev wrote: > >>>> +#define LCORE_BUFFER_SIZE (RTE_MAX_LCORE_VAR * RTE_MAX_LCORE) >>>> + >>>> +static void *lcore_buffer; >>>> +static size_t offset = RTE_MAX_LCORE_VAR; >>>> + >>>> +static void * >>>> +lcore_var_alloc(size_t size, size_t align) >>>> +{ >>>> + void *handle; >>>> + void *value; >>>> + >>>> + offset = RTE_ALIGN_CEIL(offset, align); >>>> + >>>> + if (offset + size > RTE_MAX_LCORE_VAR) { >>>> +#ifdef RTE_EXEC_ENV_WINDOWS >>>> + lcore_buffer = _aligned_malloc(LCORE_BUFFER_SIZE, >>>> + RTE_CACHE_LINE_SIZE); >>>> +#else >>>> + lcore_buffer = aligned_alloc(RTE_CACHE_LINE_SIZE, >>>> + LCORE_BUFFER_SIZE); >>>> +#endif >>> >>> Don't remember did that question already arise or not: >>> For debugging and health-checking purposes - would it make sense to link all >>> lcore_buffer values into a linked list? >>> So user/developer/some tool can walk over it to check that provided handle value >>> is really a valid lcore_var, etc. >>> >> >> At least you could add some basic statistics, like the total size >> allocated my lcore variables, and the number of variables. > > My thought was more about easing debugging/health-cheking, > but yes, some stats can also be collected. > Statistics could be used for debugging and maybe some kind of rudimentary sanity check. Maintaining per-variable state is not necessarily something you want to do, at least not close (spatially) to the lcore variable values. In summary, I'm yet to form an opinion what, if anything, we should have here to help debugging. To avoid bloat, I would suggest this being deferred up to a point where we have more experience with lcore variables. >> One could also add tracing. >> >>>> + RTE_VERIFY(lcore_buffer != NULL); >>>> + >>>> + offset = 0; >>>> + } >>>> +