From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>
Cc: Ruifeng Wang <ruifeng.wang@arm.com>,
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
Date: Fri, 23 Jun 2023 14:51:18 -0700 [thread overview]
Message-ID: <20230623215118.GC14396@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <4954a01e-53e3-c070-d737-a60c0042c736@lysator.liu.se>
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 <ruifeng.wang@arm.com>
> >---
> > 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);
> > ///@}
next prev parent reply other threads:[~2023-06-23 21:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 6:44 Ruifeng Wang
2023-06-21 7:29 ` Thomas Monjalon
2023-06-25 7:55 ` Ruifeng Wang
2023-06-22 18:19 ` Mattias Rönnblom
2023-06-23 21:51 ` Tyler Retzlaff [this message]
2023-06-25 8:45 ` Ruifeng Wang
2023-06-25 15:40 ` Thomas Monjalon
2023-06-25 8:17 ` Ruifeng Wang
2023-06-29 19:28 ` Mattias Rönnblom
2023-07-03 6:12 ` Ruifeng Wang
2023-06-26 7:12 ` [PATCH v2] " Ruifeng Wang
2023-06-29 19:43 ` Mattias Rönnblom
2023-07-03 7:02 ` Ruifeng Wang
2023-07-04 12:08 ` Mattias Rönnblom
2023-07-03 9:56 ` [PATCH v3] " Ruifeng Wang
2023-07-28 9:17 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230623215118.GC14396@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=roretzla@linux.microsoft.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=hofors@lysator.liu.se \
--cc=honnappa.nagarahalli@arm.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=nd@arm.com \
--cc=ruifeng.wang@arm.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).