DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz@6wind.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] memory barriers in rte_ring
Date: Thu, 27 Mar 2014 17:48:21 +0100	[thread overview]
Message-ID: <53345655.9030907@6wind.com> (raw)

Hi,

The commit 286bd05bf7 [1] removed the memory barriers in the ring
functions. This patch is present in DPDK since version 1.4.0r0, so I
guess it does not cause any issue.

But after checking the excellent Linux kernel documentation about memory
barriers [2], I'm wondering why memory barriers would not be required in
that case.

To illustrate the previous behavior (before dpdk 1.4):

   ring_enqueue()
     - move producer_head to reserve space in ring (atomically if
       multi producers)
     - write objects between producer_head and producer_tail
     - wmb() to ensure that STORE operations are issued
     - write producer_tail

   ring_dequeue()
     - move consumer_head (atomically if multi consumers)
     - rmb() to ensure that LOAD operations are issued: the read of
       consumer_head must occur before the reading of objects ptrs.
       In fact, rmb() is probably not needed here because knowing the
       value of consumer_head is required before reading the objects
       table.
     - read objects between consumer_head and consumer_tail
     - write consumer_tail

The memory barriers have been removed, but in my understanding at least
the wmb() would be needed according to the generic memory barrier
documentation. Maybe this is not needed on newest Intel processors?
Could anyone from Intel enlight me on this?

Thanks & regards,
Olivier


[1] 
http://dpdk.org/browse/dpdk/commit/lib/librte_ring/rte_ring.h?id=286bd05bf70d1da1b6017007276c267a1e012c1d

[2] http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt

             reply	other threads:[~2014-03-27 16:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 16:48 Olivier MATZ [this message]
2014-03-27 19:06 ` Stephen Hemminger
2014-03-27 19:47   ` Olivier MATZ
2014-03-27 20:20     ` Stephen Hemminger
2014-03-27 23:53       ` Venkatesan, Venky

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=53345655.9030907@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    /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).