DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: honnappa.nagarahalli@arm.com, ruifeng.wang@arm.com,
	Phil Yang <phil.yang@arm.com>,
	bruce.richardson@intel.com, konstantin.ananyev@intel.com,
	dev@dpdk.org, david.marchand@redhat.com,
	David Christensen <drc@linux.vnet.ibm.com>
Subject: Re: [dpdk-dev] atomic operations
Date: Sat, 3 Jul 2021 10:30:41 -0700	[thread overview]
Message-ID: <20210703103041.31ee7456@hermes.local> (raw)
In-Reply-To: <1879045.6WiRxTbeAL@thomas>

On Sat, 03 Jul 2021 13:29:38 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> In the deprecation notices of DPDK 21.05, we can still read this:
> "
> * rte_atomicNN_xxx: These APIs do not take memory order parameter. This does
>   not allow for writing optimized code for all the CPU architectures supported
>   in DPDK. DPDK will adopt C11 atomic operations semantics and provide wrappers
>   using C11 atomic built-ins. These wrappers must be used for patches that
>   need to be merged in 20.08 onwards. This change will not introduce any
>   performance degradation.
> 
> * rte_smp_*mb: These APIs provide full barrier functionality. However, many
>   use cases do not require full barriers. To support such use cases, DPDK will
>   adopt C11 barrier semantics and provide wrappers using C11 atomic built-ins.
>   These wrappers must be used for patches that need to be merged in 20.08
>   onwards. This change will not introduce any performance degradation.
> "
> 
> Should we keep these notifications forever?
> 
> It is very difficult to find which wrapper to use.
> 
> This is the guide we have:
> https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks-and-atomic-operations
> There are 2 blog posts:
> https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory-model/
> https://www.dpdk.org/blog/2021/06/09/reader-writer-concurrency/
> 
> Basically it says we should use "__atomic builtins" but there is example
> for simple situations like counters, memory barriers, etc.
> Please who could work on improving the documentation?
> 
> 

Maybe there needs to be a DPDK version of the infamous kernel documentation
of memory barriers.

  reply	other threads:[~2021-07-03 17:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 11:29 Thomas Monjalon
2021-07-03 17:30 ` Stephen Hemminger [this message]
2021-07-04  0:40   ` Thomas Monjalon
2021-07-04  0:37 ` Thomas Monjalon
2021-07-05  7:00   ` Ruifeng Wang
2021-07-05  7:30     ` Thomas Monjalon
2021-07-05  8:33       ` Ruifeng Wang
2021-07-05 16:20         ` Stephen Hemminger
2021-07-07 19:04 ` Honnappa Nagarahalli
2021-07-07 19:28   ` 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=20210703103041.31ee7456@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=drc@linux.vnet.ibm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=phil.yang@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).