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 E4BE945A78; Tue, 15 Oct 2024 21:02:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2A70400D7; Tue, 15 Oct 2024 21:02:51 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 62751400D6 for ; Tue, 15 Oct 2024 21:02:50 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E303D15B46 for ; Tue, 15 Oct 2024 21:02:49 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id D78E915B8D; Tue, 15 Oct 2024 21:02:49 +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 ECD8A15B45; Tue, 15 Oct 2024 21:02:47 +0200 (CEST) Message-ID: Date: Tue, 15 Oct 2024 21:02:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v13 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 Cc: Stephen Hemminger , Konstantin Ananyev , David Marchand , Jerin Jacob , Luka Jankovic , Konstantin Ananyev , Chengwen Feng References: <20241015065505.823840-2-mattias.ronnblom@ericsson.com> <20241015093344.824073-1-mattias.ronnblom@ericsson.com> <20241015093344.824073-2-mattias.ronnblom@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35E9F7DB@smartserver.smartshare.dk> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F7DB@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-15 12:13, Morten Brørup wrote: >> +void * >> +rte_lcore_var_alloc(size_t size, size_t align) >> +{ >> + /* Having the per-lcore buffer size aligned on cache lines >> + * assures as well as having the base pointer aligned on cache >> + * size assures that aligned offsets also translate to alipgned >> + * pointers across all values. >> + */ >> + RTE_BUILD_BUG_ON(RTE_MAX_LCORE_VAR % RTE_CACHE_LINE_SIZE != 0); >> + RTE_VERIFY(align <= RTE_CACHE_LINE_SIZE); >> + RTE_VERIFY(size <= RTE_MAX_LCORE_VAR); >> + >> + /* '0' means asking for worst-case alignment requirements */ >> + if (align == 0) >> +#ifdef RTE_TOOLCHAIN_MSVC >> + /* MSVC is missing the max_align_t typedef */ >> + align = alignof(double); >> +#else >> + align = alignof(max_align_t); >> +#endif > > Do we need worst-case alignment, or does automatic alignment suffice: > I think the term is "natural alignment." As I think I mentioned at some point, I don't really have an opinion. Worst case (max_alignt_t) alignment is the same as malloc(), so potentially what the user may expect. On the other hand, I can't see why natural alignment (or alignof(max_align_t), whichever is smallest) would not always suffice. It is a bit harder to explain in the API docs what alignment you actually get in case you don't go for worst-case alignment. I think it doesn't matter much, because the user will very likely use the typed macros (and get whatever alignment the compiler deems appropriate for that type). > /* '0' means asking for automatic alignment requirements */ > if (align == 0) { > #ifdef RTE_ARCH_64 > align = rte_align64pow2(size); > #else > align = rte_align32pow2(size); > #endif > #ifdef RTE_TOOLCHAIN_MSVC > /* MSVC is missing the max_align_t typedef */ > align = RTE_MIN(align, alignof(double)); > #else > align = RTE_MIN(align, alignof(max_align_t)); > #endif > } > > It will pack small-size lcore variables even tighter. >