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 A423D42D34; Fri, 23 Jun 2023 23:51:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AE99340ED7; Fri, 23 Jun 2023 23:51:20 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id AA8E440693 for ; Fri, 23 Jun 2023 23:51:19 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id C9A1E21C2544; Fri, 23 Jun 2023 14:51:18 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com C9A1E21C2544 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1687557078; bh=BSKPX/CibzY+aMMMu0ZjgX45cbyQBwmPbpl9Pvn9U2Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iJNCAbJPWfhcE05Px5AF5YBolSulFu7TSsC1eeHCbLV6eDRJRnNuWo/AH4BnS3Umb KfbO3bj8lIBunYOz++xnim1qlzXChZxg9a2jauBAQGEvkeN1LXevpztIeRIDMbA85O xmc+tcDDNtRRZ0veYwzgIGHiTgyfU0P/njsUcCUg= Date: Fri, 23 Jun 2023 14:51:18 -0700 From: Tyler Retzlaff To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Ruifeng Wang , thomas@monjalon.net, david.marchand@redhat.com, dev@dpdk.org, konstantin.v.ananyev@yandex.ru, honnappa.nagarahalli@arm.com, nd@arm.com Subject: Re: [PATCH] eal: add notes to SMP memory barrier APIs Message-ID: <20230623215118.GC14396@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230621064420.163931-1-ruifeng.wang@arm.com> <4954a01e-53e3-c070-d737-a60c0042c736@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4954a01e-53e3-c070-d737-a60c0042c736@lysator.liu.se> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Thu, Jun 22, 2023 at 08:19:30PM +0200, Mattias Rönnblom wrote: > On 2023-06-21 08:44, Ruifeng Wang wrote: > >The rte_smp_xx() APIs are deprecated. But it is not mentioned > >in the function header. > >Added notes in function header for clarification. > > > >Signed-off-by: Ruifeng Wang > >--- > > lib/eal/include/generic/rte_atomic.h | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > >diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h > >index 58df843c54..542a2c16ff 100644 > >--- a/lib/eal/include/generic/rte_atomic.h > >+++ b/lib/eal/include/generic/rte_atomic.h > >@@ -55,6 +55,11 @@ static inline void rte_rmb(void); > > * Guarantees that the LOAD and STORE operations that precede the > > * rte_smp_mb() call are globally visible across the lcores > > * before the LOAD and STORE operations that follows it. > >+ * > >+ * @note > >+ * This function is deprecated. It adds complexity to the memory model > >+ * used by this project. C11 memory model should always be used. > >+ * rte_atomic_thread_fence() should be used instead. > > It's somewhat confusing to learn I should use the C11 memory model, > and then in the next sentence that I should call a function which is > not in C11. i wonder if we can just do without the comments until we begin to adopt changes for 23.11 release because the guidance will be short lived. in 23.07 we want to say that only gcc builtins that align with the standard C++ memory model should be used. in 23.11 we want to say that only standard C11 atomics should be used. my suggestion i guess is just adapt the patch to be appropriate for 23.11 and only merge it after 23.07 release? might be easier to manage. > > I think it would be helpful to say which memory_model parameters > should be used to replace the rte_smp_*mb() calls, and if there are > any difference in semantics between the Linux kernel-style barriers > and their C11 (near-)equivalents. > > Is there some particular reason these functions aren't marked > __rte_deprecated? Too many warnings? > > > */ > > static inline void rte_smp_mb(void); > >@@ -64,6 +69,11 @@ static inline void rte_smp_mb(void); > > * Guarantees that the STORE operations that precede the > > * rte_smp_wmb() call are globally visible across the lcores > > * before the STORE operations that follows it. > >+ * > >+ * @note > >+ * This function is deprecated. It adds complexity to the memory model > >+ * used by this project. C11 memory model should always be used. > >+ * rte_atomic_thread_fence() should be used instead. > > */ > > static inline void rte_smp_wmb(void); > >@@ -73,6 +83,11 @@ static inline void rte_smp_wmb(void); > > * Guarantees that the LOAD operations that precede the > > * rte_smp_rmb() call are globally visible across the lcores > > * before the LOAD operations that follows it. > >+ * > >+ * @note > >+ * This function is deprecated. It adds complexity to the memory model > >+ * used by this project. C11 memory model should always be used. > >+ * rte_atomic_thread_fence() should be used instead. > > */ > > static inline void rte_smp_rmb(void); > > ///@}