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 4F11843095; Fri, 18 Aug 2023 09:13:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D7D0410FD; Fri, 18 Aug 2023 09:13:34 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 3028840ED9; Fri, 18 Aug 2023 09:13:32 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 0A56A20634; Fri, 18 Aug 2023 09:13:32 +0200 (CEST) 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 v4 6/6] devtools: forbid new direct use of GCC atomic builtins Date: Fri, 18 Aug 2023 09:13:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87B1A@smartserver.smartshare.dk> In-Reply-To: <20230817191408.GB12307@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v4 6/6] devtools: forbid new direct use of GCC atomic builtins Thread-Index: AdnRPwCkhih4JXm5Tz+e89AiSl7JuwAYlQFg References: <1691717521-1025-1-git-send-email-roretzla@linux.microsoft.com> <1692221931-32334-1-git-send-email-roretzla@linux.microsoft.com> <1692221931-32334-7-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D87B16@smartserver.smartshare.dk> <20230817191408.GB12307@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Bruce Richardson" Cc: , , "Honnappa Nagarahalli" , "Ruifeng Wang" , "Jerin Jacob" , "Sunil Kumar Kori" , =?iso-8859-1?Q?Mattias_R=F6nnblom?= , "Joyce Kong" , "David Christensen" , "Konstantin Ananyev" , "David Hunt" , "Thomas Monjalon" , "David Marchand" 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, 17 August 2023 21.14 >=20 > On Thu, Aug 17, 2023 at 01:57:01PM +0200, Morten Br=F8rup wrote: > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > Sent: Wednesday, 16 August 2023 23.39 > > > > > > Refrain from using compiler __atomic_xxx builtins DPDK now = requires > > > the use of rte_atomic__explicit macros when operating on DPDK > > > atomic variables. > > > > There is probably no end to how much can be added to checkpatches. > > > > You got the important stuff, so below are only further suggestions! > > > > [...] > > > > > - # refrain from using compiler = __atomic_{add,and,nand,or,sub,xor}_fetch() > > > + # refrain from using compiler __atomic_xxx builtins > > > awk -v FOLDERS=3D"lib drivers app examples" \ > > > - -v EXPRESSIONS=3D"__atomic_(add|and|nand|or|sub|xor)_fetch\\\(" = \ > > > + -v EXPRESSIONS=3D"__atomic_.*\\\(" \ > > > -v RET_ON_FAIL=3D1 \ > > > - -v MESSAGE=3D'Using __atomic_op_fetch, prefer = __atomic_fetch_op' \ > > > + -v MESSAGE=3D'Using __atomic_xxx builtins' \ > > > > Alternatively: > > -v MESSAGE=3D'Using __atomic_xxx built-ins, prefer rte_atomic_xxx' > \ >=20 > i can adjust the wording as you suggest, no problem >=20 > > > > > -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ > > > "$1" || res=3D1 > > > > > > -- > > > 1.8.3.1 > > > > This could be updated too: > > > > # refrain from using compiler __atomic_thread_fence() > > # It should be avoided on x86 for SMP case. > > awk -v FOLDERS=3D"lib drivers app examples" \ > > -v EXPRESSIONS=3D"__atomic_thread_fence\\\(" \ > > -v RET_ON_FAIL=3D1 \ > > - -v MESSAGE=3D'Using __atomic_thread_fence' \ > > + -v MESSAGE=3D'Using __atomic_thread_fence built-in, prefer > __rte_atomic_thread_fence' \ > > -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \ >=20 > yeah, i left this one separate i think the advice is actually use > rte_atomic_thread_fence which may be an inline function that uses > __rte_atomic_thread_fence I now noticed that the comment to this says "# [...] should be avoided = on x86 for SMP case." Wouldn't that apply to __rte_atomic_thread_fence = too? So would we want a similar warning for __rte_atomic_thread_fence in = checkpatches; i.e. warnings for all variants of = [__[rte_]]atomic_thread_fence? If the use of [__[rte_]]atomic_thread_fence is only conditionally = prohibited, I think that we should move the warning to the definition of = __rte_atomic_thread_fence itself, gated by x64 and SMP being defined. = The CI would catch its use in DPDK, but still allow application = developers to use it (for targets not being x86 SMP). What do others = think? >=20 > > "$1" || res=3D1 > > > > You could also add C11 variants of these tests... > > > = atomic_(load|store|exchange|compare_exchange_(strong|weak)|fetch_(add|sub= |and| > xor|or|nand)|flag_(test_and_set|clear))[_explicit], and > > atomic_thread_fence. > > > > And a test for using "_Atomic". >=20 > direct use would cause early compilation in the CI so it would be = caught > fairly early. i'm not sure i want to get into the business of trying = to > add redundant (albiet cheaper) earlier checks. >=20 > though if there is a general call for this from the reviewers i'll add > them.