DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Richardson, Bruce" <bruce.richardson@intel.com>
To: Chao CH Zhu <bjzhuc@cn.ibm.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM	Power	architecture
Date: Thu, 16 Oct 2014 09:42:46 +0000	[thread overview]
Message-ID: <59AF69C657FD0841A61C55336867B5B03441F561@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <OFCD69120A.E4F3D7D4-ON48257D73.0011507B-48257D73.0011E4AC@cn.ibm.com>

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Chao CH Zhu
> Sent: Thursday, October 16, 2014 4:14 AM
> To: Ananyev, Konstantin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power
> architecture
> 
> Konstantin,
> 
> In my understanding, compiler barrier is a kind of software barrier which
> prevents the compiler from moving memory accesses across the barrier. This
> should be architecture-independent. And the "sync" instruction is a
> hardware barrier which depends on PowerPC architecture. So I think the
> compiler barrier should be the same on x86 and PowerPC. Any comments?
> Please correct me if I was wrong.
> 
I would agree with that assessment, as far as it goes, in that a compiler barrier is going to be the same on both architectures. However, we also need to start thinking about actual use cases - how to we specify the barriers in a piece of code where we need a full memory barrier on PPC and only a compiler barrier on IA? 
My suggestion would be to do first as you propose and have proper primitives for the different barrier types defined correctly for each platform - with the compiler barrier being, presumably, common across each one. Then, as a second step, we probably need to look at defining "logical" barrier types (for want of a better term) that can then be used in the code and which would be different across platforms.

Does this make sense to do this way? Is it the best solution? Do we want to define the basic primitives or are we only ever likely to need the logical barrier types?

/Bruce

  reply	other threads:[~2014-10-16  9:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26  9:36 [dpdk-dev] [PATCH 00/12] Patches for DPDK to support " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 01/12] Add compiling definations for IBM " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 02/12] Add atomic operations " Chao Zhu
2014-09-29  6:16   ` Hemant
2014-09-29  6:41     ` Chao CH Zhu
2014-10-16  0:39   ` Ananyev, Konstantin
2014-10-16  3:14     ` Chao CH Zhu
2014-10-16  9:42       ` Richardson, Bruce [this message]
2014-10-16 11:04         ` Ananyev, Konstantin
     [not found]       ` <2601191342CEEE43887BDE71AB97725821393F5D@IRSMSX105.ger.corp.intel.com>
2014-10-16 10:59         ` Ananyev, Konstantin
2014-09-26  9:36 ` [dpdk-dev] [PATCH 03/12] Add byte order " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 04/12] Add CPU cycle " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 05/12] Add prefetch operation " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 06/12] Add spinlock " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 07/12] Add vector memcpy " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 08/12] Add CPU flag checking " Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 09/12] Remove iopl operation " Chao Zhu
2014-10-06 22:03   ` Cyril Chemparathy
2014-10-07 14:46     ` Ananyev, Konstantin
2014-10-13  2:33       ` Chao CH Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 10/12] Add cache size define for IBM Power Architecture Chao Zhu
2014-09-29  6:21   ` Hemant
2014-09-26  9:36 ` [dpdk-dev] [PATCH 11/12] Add huge page sizes for IBM Power architecture Chao Zhu
2014-09-26  9:36 ` [dpdk-dev] [PATCH 12/12] Add memory support for IBM Power Architecture Chao Zhu
2014-11-13 10:24 ` [dpdk-dev] [PATCH 00/12] Patches for DPDK to support Power architecture Thomas Monjalon
2014-11-13 10:31   ` Chao Zhu

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=59AF69C657FD0841A61C55336867B5B03441F561@IRSMSX103.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=bjzhuc@cn.ibm.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    /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).