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 EF60843A0F; Tue, 30 Jan 2024 19:18:51 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DF8FE427E5; Tue, 30 Jan 2024 19:18:51 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id D2BD5427E4 for ; Tue, 30 Jan 2024 19:18:50 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 45CF213120 for ; Tue, 30 Jan 2024 19:18:50 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 39932131B2; Tue, 30 Jan 2024 19:18:50 +0100 (CET) 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.4 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.4 Received: from [192.168.1.59] (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 82B0D13055; Tue, 30 Jan 2024 19:18:47 +0100 (CET) Message-ID: <948697d6-53a4-424c-a761-6da1a1cbed02@lysator.liu.se> Date: Tue, 30 Jan 2024 19:18:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RFC: use C11 alignas instead of GCC attribute aligned To: Bruce Richardson , Tyler Retzlaff Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , dev@dpdk.org, =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Anatoly Burakov , David Christensen , Harry van Haaren , Konstantin Ananyev , Min Zhou , Ruifeng Wang , Stanislaw Kardach , thomas@monjalon.net References: <20240125183713.GA27715@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35E9F1A3@smartserver.smartshare.dk> <91ba1ece-10dd-4698-acd9-6b51cfc63cd9@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F1A7@smartserver.smartshare.dk> <635f0d9f-6665-426b-b778-d61e5e732fbe@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35E9F1AA@smartserver.smartshare.dk> <413840c1-a263-4118-adfe-d4ae0ec0b52d@lysator.liu.se> <20240129194356.GA25654@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20240130173928.GA2943@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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: 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-01-30 18:59, Bruce Richardson wrote: > On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote: >> On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote: > >>> >>> Sorry if I've missed some discussion on the list, but the current >>> pattern of putting __rte_aligned(X) at the end doesn't work with MSVC, >>> or why are we doing this? C11 purism doesn't seem like much of a >>> driving force. >> >> __rte_aligned(X) at the end doesn't work with MSVC __declspec(align(n)) >> >>> >>> If one defined a macro as __declspec(align(X)) on MSVC and >>> __attribute__(__aligned__(X)) on other compilers, could it do the work >>> of both the above RTE_ALIGNAS() and RTE_ALIGN_TYPE()? >>> >>> struct { int a; } ; >> >> yes for struct/union. but only when placed at location you mark as >> when compiling both C and C++ for all toolchains. >> > I can see this restriction on placement potentially causing problems. Maybe > we should consider defining macros with the "struct" keywork included. For > example, (using gcc attributes here): > > #define rte_aligned_struct(n) struct __attribute((aligned(n))) > > rte_aligned_struct my_struct { > int a; > } > > Probably that's taking things a bit far away from standard C, but it may > cut down on placement errors. It doesn't go well with the fact alignment is just one of several attributes one may want to add to a struct (__rte_packed is another). A quick scan of the DPDK source tree suggests DPDK developers are pretty good at putting the old __rte_cache_aligned consistently after the struct declaration (i.e., position per above). Conservative as they may be, perhaps they could be rewired to consistently put it somewhere else.