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 C5EFE439C5; Thu, 25 Jan 2024 23:53:12 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41B7F402AB; Thu, 25 Jan 2024 23:53:12 +0100 (CET) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id BB0684029B for ; Thu, 25 Jan 2024 23:53:10 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 78FA3207C3; Thu, 25 Jan 2024 23:53:10 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] RFC: use C11 alignas instead of GCC attribute aligned X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 25 Jan 2024 23:53:04 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F1A3@smartserver.smartshare.dk> In-Reply-To: <20240125183713.GA27715@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] RFC: use C11 alignas instead of GCC attribute aligned Thread-Index: AdpPvYeWqE5rNO2kSqmCBj3PSlLPnAAIOM0Q References: <1700069997-4399-1-git-send-email-roretzla@linux.microsoft.com> <20240125183713.GA27715@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , Cc: =?iso-8859-1?Q?Mattias_R=F6nnblom?= , "Anatoly Burakov" , "Bruce Richardson" , "David Christensen" , "Harry van Haaren" , "Konstantin Ananyev" , "Min Zhou" , "Ruifeng Wang" , "Stanislaw Kardach" , 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 > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Thursday, 25 January 2024 19.37 >=20 > ping. >=20 > Please review this thread if you have time, the main point of > discussion > I would like to receive consensus on the following questions. >=20 > 1. Should we continue to expand common alignments behind an = __rte_macro >=20 > i.e. what do we prefer to appear in code >=20 > alignas(RTE_CACHE_LINE_MIN_SIZE) >=20 > -- or -- >=20 > __rte_cache_aligned >=20 > One of the benefits of dropping the macro is it provides a clear = visual > indicator that it is not placed in the same location or get applied > to types as is done with __attribute__((__aligned__(n))). We don't want our own proprietary variant of something that already = exists in the C standard. Now that we have moved to C11, the __rte = alignment macros should be considered obsolete. Note: I don't mind convenience macros for common use cases, so we could = also introduce the macro suggested by Mattias [1]: #define RTE_CACHE_ALIGNAS alignas(RTE_CACHE_LINE_SIZE) [1]: = https://inbox.dpdk.org/dev/dc3f3131-38e6-4219-861e-b31ec10c08bb@lysator.l= iu.se/ >=20 > 2. where should we place alignas(n) or __rte_macro (if we use a macro) >=20 > Should it be on the same line as the variable or field or on the > preceeding line? >=20 > /* same line example struct */ > struct T { > /* alignas(64) applies to field0 *not* struct T type declaration > */ > alignas(64) void *field0; > void *field1; >=20 > ... other fields ... >=20 > alignas(64) uint64_t field5; > uint32_t field6; >=20 > ... more fields ... >=20 > }; >=20 > /* same line example array */ > alignas(64) static const uint32_t array[4] =3D { ... }; >=20 > -- or -- >=20 > /* preceeding line example struct */ > struct T { > /* alignas(64) applies to field0 *not* struct T type declaration > */ > alignas(64) > void *field0; > void *field1; >=20 > ... other fields ... >=20 > alignas(64) > uint64_t field5; > uint32_t field6; >=20 > ... more fields ... >=20 > }; >=20 > /* preceeding line example array */ > alignas(64) > static const uint32_t array[4] =3D { ... }; >=20 Searching the net for what other projects do, I came across this = required placement [2]: uint64_t alignas(64) field5; [2]: = https://lore.kernel.org/buildroot/20230730000851.6faa3391@windsurf/T/ So let's follow the standard's intention and put them on the same line. On an case-by-case basis, we can wrap lines if it improves readability, = like we do with function headers that have a lot of attributes. >=20 > I'll submit patches for lib/* once the discussion is concluded. >=20 > thanks folks