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 3F0A145B04; Thu, 10 Oct 2024 15:40:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32BDD40612; Thu, 10 Oct 2024 15:40:19 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 8A1A140612 for ; Thu, 10 Oct 2024 15:40:17 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 45D551F3F9 for ; Thu, 10 Oct 2024 15:40:17 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 39A2A1F3F8; Thu, 10 Oct 2024 15:40:17 +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.85] (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 2FD671F3F6; Thu, 10 Oct 2024 15:40:15 +0200 (CEST) Message-ID: <489dfdd8-30f4-4ab7-82a6-cccfdfc01093@lysator.liu.se> Date: Thu, 10 Oct 2024 15:40:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 1/7] eal: add static per-lcore memory allocation facility To: =?UTF-8?Q?Morten_Br=C3=B8rup?= , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , dev@dpdk.org, Tyler Retzlaff Cc: Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob References: <20240918080054.725164-2-mattias.ronnblom@ericsson.com> <20240918082614.725220-1-mattias.ronnblom@ericsson.com> <20240918082614.725220-2-mattias.ronnblom@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35E9F7B3@smartserver.smartshare.dk> <70facd2d-771f-47d7-b6d3-67a142607ef1@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F7B6@smartserver.smartshare.dk> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F7B6@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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-10-10 13:47, Morten Brørup wrote: >> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se] >> Sent: Thursday, 10 October 2024 12.40 >> >> On 2024-10-10 00:15, Morten Brørup wrote: >>>> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com] >>>> Sent: Wednesday, 18 September 2024 10.26 >>>> >>>> Introduce DPDK per-lcore id variables, or lcore variables for short. >>>> >>>> An lcore variable has one value for every current and future lcore >>>> id-equipped thread. >>>> >>>> The primary use case is for statically allocating >>>> small, frequently-accessed data structures, for which one instance >>>> should exist for each lcore. >>>> >>>> Lcore variables are similar to thread-local storage (TLS, e.g., C11 >>>> _Thread_local), but decoupling the values' life time with that of >> the >>>> threads. >>>> >>>> Lcore variables are also similar in terms of functionality provided >> by >>>> FreeBSD kernel's DPCPU_*() family of macros and the associated >>>> build-time machinery. DPCPU uses linker scripts, which effectively >>>> prevents the reuse of its, otherwise seemingly viable, approach. >>>> >>>> The currently-prevailing way to solve the same problem as lcore >>>> variables is to keep a module's per-lcore data as RTE_MAX_LCORE- >> sized >>>> array of cache-aligned, RTE_CACHE_GUARDed structs. The benefit of >>>> lcore variables over this approach is that data related to the same >>>> lcore now is close (spatially, in memory), rather than data used by >>>> the same module, which in turn avoid excessive use of padding, >>>> polluting caches with unused data. >>>> >>>> Signed-off-by: Mattias Rönnblom >>>> Acked-by: Morten Brørup >>> >>>> --- /dev/null >>>> +++ b/lib/eal/common/eal_common_lcore_var.c >>>> @@ -0,0 +1,79 @@ >>>> +/* SPDX-License-Identifier: BSD-3-Clause >>>> + * Copyright(c) 2024 Ericsson AB >>>> + */ >>>> + >>>> +#include >>>> +#include >>>> + >>>> +#ifdef RTE_EXEC_ENV_WINDOWS >>>> +#include >>>> +#endif >>> >>> From what I can read on the internet, max_align_t is missing in >> stddef.h in MSVC [1], so try adding this to fix the Windows CI >> compilation failure: >>> >>> #ifdef RTE_TOOLCHAIN_MSVC >>> #include >>> #endif >> >> Please excuse my MSVC ignorance, but will this work in C? Looks like >> C++. > > I have no clue. Just parroting what Microsoft says on the internet. > > You can try it out and see if the CI accepts it. > It wouldn't make sense if that worked, so I'll go for this instead: #ifdef RTE_TOOLCHAIN_MSVC /* MSVC is missing the max_align_t typedef */ align = alignof(double); #else align = alignof(max_align_t); #endif Thanks for pointing out this issue. >> >>> >>> [1]: https://learn.microsoft.com/en-ie/answers/questions/1726147/why- >> max-align-t-not-defined-in-stddef-h-in-windows >>> > > I would like to see this series go into 24.11, and then it needs to work for MSVC too. > > @Tyler, any better suggestions for fixing the missing max_align_t in stddef.h? >