DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
@ 2015-11-03 15:52 Jerin Jacob
  2015-11-03 15:57 ` simon barber
  2015-11-03 15:57 ` Ananyev, Konstantin
  0 siblings, 2 replies; 10+ messages in thread
From: Jerin Jacob @ 2015-11-03 15:52 UTC (permalink / raw)
  To: dev

rte_ring implementation needs explicit memory barrier
in weakly ordered architecture like ARM unlike
strongly ordered architecture like X86

Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
configuration to abstract such dependency so that other
weakly ordered architectures can reuse this infrastructure.

Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
 config/common_bsdapp                         |  5 +++++
 config/common_linuxapp                       |  5 +++++
 config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
 config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
 lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
 5 files changed, 32 insertions(+)

diff --git a/config/common_bsdapp b/config/common_bsdapp
index b37dcf4..c8d1f63 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_ARCH_STRICT_ALIGN=n
 
 #
+# Machine has strongly-ordered memory operations on normal memory like x86
+#
+CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
+
+#
 # Compile to share library
 #
 CONFIG_RTE_BUILD_SHARED_LIB=n
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0de43d5..d040a74 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_ARCH_STRICT_ALIGN=n
 
 #
+# Machine has strongly-ordered memory operations on normal memory like x86
+#
+CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
+
+#
 # Compile to share library
 #
 CONFIG_RTE_BUILD_SHARED_LIB=n
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 6ea38a5..5289152 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
 CONFIG_RTE_ARCH_ARM64=y
 CONFIG_RTE_ARCH_64=y
 CONFIG_RTE_ARCH_ARM_NEON=y
+CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
 
 CONFIG_RTE_FORCE_INTRINSICS=y
 
diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
index e8fccc7..79fa9e6 100644
--- a/config/defconfig_arm64-thunderx-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
@@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
 CONFIG_RTE_ARCH_ARM64=y
 CONFIG_RTE_ARCH_64=y
 CONFIG_RTE_ARCH_ARM_NEON=y
+CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
 
 CONFIG_RTE_FORCE_INTRINSICS=y
 
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af68888..1ccd186 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
 
 	/* write entries in ring */
 	ENQUEUE_PTRS();
+
+#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
 	rte_compiler_barrier();
+#else
+	rte_wmb();
+#endif
 
 	/* if we exceed the watermark */
 	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
@@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
 
 	/* write entries in ring */
 	ENQUEUE_PTRS();
+
+#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
 	rte_compiler_barrier();
+#else
+	rte_wmb();
+#endif
 
 	/* if we exceed the watermark */
 	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
@@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
 
 	/* copy in table */
 	DEQUEUE_PTRS();
+
+#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
 	rte_compiler_barrier();
+#else
+	rte_rmb();
+#endif
 
 	/*
 	 * If there are other dequeues in progress that preceded us,
@@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
 
 	/* copy in table */
 	DEQUEUE_PTRS();
+
+#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
 	rte_compiler_barrier();
+#else
+	rte_rmb();
+#endif
 
 	__RING_STAT_ADD(r, deq_success, n);
 	r->cons.tail = cons_next;
-- 
2.1.0

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 15:52 [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter Jerin Jacob
@ 2015-11-03 15:57 ` simon barber
  2015-11-03 15:57 ` Ananyev, Konstantin
  1 sibling, 0 replies; 10+ messages in thread
From: simon barber @ 2015-11-03 15:57 UTC (permalink / raw)
  To: dev

Do we need to have all these #ifdef, it looks messy, can you not define 
a macro that is defined based upon

  
RTE_ARCH_STRONGLY_ORDERED_MEM_OP


/Simon


On 11/03/2015 03:52 PM, Jerin Jacob wrote:
> rte_ring implementation needs explicit memory barrier
> in weakly ordered architecture like ARM unlike
> strongly ordered architecture like X86
>
> Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> configuration to abstract such dependency so that other
> weakly ordered architectures can reuse this infrastructure.
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
>   config/common_bsdapp                         |  5 +++++
>   config/common_linuxapp                       |  5 +++++
>   config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
>   config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
>   lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
>   5 files changed, 32 insertions(+)
>
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index b37dcf4..c8d1f63 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>   CONFIG_RTE_ARCH_STRICT_ALIGN=n
>   
>   #
> +# Machine has strongly-ordered memory operations on normal memory like x86
> +#
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> +
> +#
>   # Compile to share library
>   #
>   CONFIG_RTE_BUILD_SHARED_LIB=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 0de43d5..d040a74 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>   CONFIG_RTE_ARCH_STRICT_ALIGN=n
>   
>   #
> +# Machine has strongly-ordered memory operations on normal memory like x86
> +#
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> +
> +#
>   # Compile to share library
>   #
>   CONFIG_RTE_BUILD_SHARED_LIB=n
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 6ea38a5..5289152 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
>   CONFIG_RTE_ARCH_ARM64=y
>   CONFIG_RTE_ARCH_64=y
>   CONFIG_RTE_ARCH_ARM_NEON=y
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
>   
>   CONFIG_RTE_FORCE_INTRINSICS=y
>   
> diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> index e8fccc7..79fa9e6 100644
> --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
>   CONFIG_RTE_ARCH_ARM64=y
>   CONFIG_RTE_ARCH_64=y
>   CONFIG_RTE_ARCH_ARM_NEON=y
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
>   
>   CONFIG_RTE_FORCE_INTRINSICS=y
>   
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index af68888..1ccd186 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
>   
>   	/* write entries in ring */
>   	ENQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>   	rte_compiler_barrier();
> +#else
> +	rte_wmb();
> +#endif
>   
>   	/* if we exceed the watermark */
>   	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
>   
>   	/* write entries in ring */
>   	ENQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>   	rte_compiler_barrier();
> +#else
> +	rte_wmb();
> +#endif
>   
>   	/* if we exceed the watermark */
>   	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
>   
>   	/* copy in table */
>   	DEQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>   	rte_compiler_barrier();
> +#else
> +	rte_rmb();
> +#endif
>   
>   	/*
>   	 * If there are other dequeues in progress that preceded us,
> @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
>   
>   	/* copy in table */
>   	DEQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>   	rte_compiler_barrier();
> +#else
> +	rte_rmb();
> +#endif
>   
>   	__RING_STAT_ADD(r, deq_success, n);
>   	r->cons.tail = cons_next;

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 15:52 [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter Jerin Jacob
  2015-11-03 15:57 ` simon barber
@ 2015-11-03 15:57 ` Ananyev, Konstantin
  2015-11-03 16:18   ` Jerin Jacob
  1 sibling, 1 reply; 10+ messages in thread
From: Ananyev, Konstantin @ 2015-11-03 15:57 UTC (permalink / raw)
  To: Jerin Jacob, dev



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> Sent: Tuesday, November 03, 2015 3:52 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> 
> rte_ring implementation needs explicit memory barrier
> in weakly ordered architecture like ARM unlike
> strongly ordered architecture like X86
> 
> Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> configuration to abstract such dependency so that other
> weakly ordered architectures can reuse this infrastructure.

Looks a bit clumsy.
Please try to follow this suggestion instead:
http://dpdk.org/ml/archives/dev/2015-October/025505.html

Konstantin

> 
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
>  config/common_bsdapp                         |  5 +++++
>  config/common_linuxapp                       |  5 +++++
>  config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
>  config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
>  lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
>  5 files changed, 32 insertions(+)
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index b37dcf4..c8d1f63 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> 
>  #
> +# Machine has strongly-ordered memory operations on normal memory like x86
> +#
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> +
> +#
>  # Compile to share library
>  #
>  CONFIG_RTE_BUILD_SHARED_LIB=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 0de43d5..d040a74 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> 
>  #
> +# Machine has strongly-ordered memory operations on normal memory like x86
> +#
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> +
> +#
>  # Compile to share library
>  #
>  CONFIG_RTE_BUILD_SHARED_LIB=n
> diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> index 6ea38a5..5289152 100644
> --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
>  CONFIG_RTE_ARCH_ARM64=y
>  CONFIG_RTE_ARCH_64=y
>  CONFIG_RTE_ARCH_ARM_NEON=y
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> 
>  CONFIG_RTE_FORCE_INTRINSICS=y
> 
> diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> index e8fccc7..79fa9e6 100644
> --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
>  CONFIG_RTE_ARCH_ARM64=y
>  CONFIG_RTE_ARCH_64=y
>  CONFIG_RTE_ARCH_ARM_NEON=y
> +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> 
>  CONFIG_RTE_FORCE_INTRINSICS=y
> 
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index af68888..1ccd186 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> 
>  	/* write entries in ring */
>  	ENQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>  	rte_compiler_barrier();
> +#else
> +	rte_wmb();
> +#endif
> 
>  	/* if we exceed the watermark */
>  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> 
>  	/* write entries in ring */
>  	ENQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>  	rte_compiler_barrier();
> +#else
> +	rte_wmb();
> +#endif
> 
>  	/* if we exceed the watermark */
>  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
> 
>  	/* copy in table */
>  	DEQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>  	rte_compiler_barrier();
> +#else
> +	rte_rmb();
> +#endif
> 
>  	/*
>  	 * If there are other dequeues in progress that preceded us,
> @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
> 
>  	/* copy in table */
>  	DEQUEUE_PTRS();
> +
> +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
>  	rte_compiler_barrier();
> +#else
> +	rte_rmb();
> +#endif
> 
>  	__RING_STAT_ADD(r, deq_success, n);
>  	r->cons.tail = cons_next;
> --
> 2.1.0

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 15:57 ` Ananyev, Konstantin
@ 2015-11-03 16:18   ` Jerin Jacob
  2015-11-03 16:24     ` Richardson, Bruce
  2015-11-03 16:28     ` Ananyev, Konstantin
  0 siblings, 2 replies; 10+ messages in thread
From: Jerin Jacob @ 2015-11-03 16:18 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > Sent: Tuesday, November 03, 2015 3:52 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > 
> > rte_ring implementation needs explicit memory barrier
> > in weakly ordered architecture like ARM unlike
> > strongly ordered architecture like X86
> > 
> > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > configuration to abstract such dependency so that other
> > weakly ordered architectures can reuse this infrastructure.
> 
> Looks a bit clumsy.
> Please try to follow this suggestion instead:
> http://dpdk.org/ml/archives/dev/2015-October/025505.html

Make sense. Do we agree on a macro that is defined based upon
RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?

Jerin

> 
> Konstantin
> 
> > 
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > ---
> >  config/common_bsdapp                         |  5 +++++
> >  config/common_linuxapp                       |  5 +++++
> >  config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
> >  config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
> >  lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
> >  5 files changed, 32 insertions(+)
> > 
> > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > index b37dcf4..c8d1f63 100644
> > --- a/config/common_bsdapp
> > +++ b/config/common_bsdapp
> > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > 
> >  #
> > +# Machine has strongly-ordered memory operations on normal memory like x86
> > +#
> > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > +
> > +#
> >  # Compile to share library
> >  #
> >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > index 0de43d5..d040a74 100644
> > --- a/config/common_linuxapp
> > +++ b/config/common_linuxapp
> > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > 
> >  #
> > +# Machine has strongly-ordered memory operations on normal memory like x86
> > +#
> > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > +
> > +#
> >  # Compile to share library
> >  #
> >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > index 6ea38a5..5289152 100644
> > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> >  CONFIG_RTE_ARCH_ARM64=y
> >  CONFIG_RTE_ARCH_64=y
> >  CONFIG_RTE_ARCH_ARM_NEON=y
> > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > 
> >  CONFIG_RTE_FORCE_INTRINSICS=y
> > 
> > diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > index e8fccc7..79fa9e6 100644
> > --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> > +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> >  CONFIG_RTE_ARCH_ARM64=y
> >  CONFIG_RTE_ARCH_64=y
> >  CONFIG_RTE_ARCH_ARM_NEON=y
> > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > 
> >  CONFIG_RTE_FORCE_INTRINSICS=y
> > 
> > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > index af68888..1ccd186 100644
> > --- a/lib/librte_ring/rte_ring.h
> > +++ b/lib/librte_ring/rte_ring.h
> > @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > 
> >  	/* write entries in ring */
> >  	ENQUEUE_PTRS();
> > +
> > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> >  	rte_compiler_barrier();
> > +#else
> > +	rte_wmb();
> > +#endif
> > 
> >  	/* if we exceed the watermark */
> >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > 
> >  	/* write entries in ring */
> >  	ENQUEUE_PTRS();
> > +
> > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> >  	rte_compiler_barrier();
> > +#else
> > +	rte_wmb();
> > +#endif
> > 
> >  	/* if we exceed the watermark */
> >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
> > 
> >  	/* copy in table */
> >  	DEQUEUE_PTRS();
> > +
> > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> >  	rte_compiler_barrier();
> > +#else
> > +	rte_rmb();
> > +#endif
> > 
> >  	/*
> >  	 * If there are other dequeues in progress that preceded us,
> > @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
> > 
> >  	/* copy in table */
> >  	DEQUEUE_PTRS();
> > +
> > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> >  	rte_compiler_barrier();
> > +#else
> > +	rte_rmb();
> > +#endif
> > 
> >  	__RING_STAT_ADD(r, deq_success, n);
> >  	r->cons.tail = cons_next;
> > --
> > 2.1.0
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 16:18   ` Jerin Jacob
@ 2015-11-03 16:24     ` Richardson, Bruce
  2015-11-03 16:28     ` Ananyev, Konstantin
  1 sibling, 0 replies; 10+ messages in thread
From: Richardson, Bruce @ 2015-11-03 16:24 UTC (permalink / raw)
  To: Jerin Jacob, Ananyev, Konstantin; +Cc: dev



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> Sent: Tuesday, November 3, 2015 4:19 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce
> RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> 
> On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Tuesday, November 03, 2015 3:52 PM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce
> > > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > >
> > > rte_ring implementation needs explicit memory barrier in weakly
> > > ordered architecture like ARM unlike strongly ordered architecture
> > > like X86
> > >
> > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration to
> > > abstract such dependency so that other weakly ordered architectures
> > > can reuse this infrastructure.
> >
> > Looks a bit clumsy.
> > Please try to follow this suggestion instead:
> > http://dpdk.org/ml/archives/dev/2015-October/025505.html
> 
> Make sense. Do we agree on a macro that is defined based upon
> RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?
> 
> Jerin

Yes to the single-defined barrier macro.
However, for what controls it, is it really worthwhile defining a new RTE_ variable for it? Can we not base it on RTE_ARCH directly?

/Bruce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 16:18   ` Jerin Jacob
  2015-11-03 16:24     ` Richardson, Bruce
@ 2015-11-03 16:28     ` Ananyev, Konstantin
  2015-11-03 16:53       ` Jerin Jacob
  1 sibling, 1 reply; 10+ messages in thread
From: Ananyev, Konstantin @ 2015-11-03 16:28 UTC (permalink / raw)
  To: Jerin Jacob; +Cc: dev



> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Tuesday, November 03, 2015 4:19 PM
> To: Ananyev, Konstantin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> 
> On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > Sent: Tuesday, November 03, 2015 3:52 PM
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > >
> > > rte_ring implementation needs explicit memory barrier
> > > in weakly ordered architecture like ARM unlike
> > > strongly ordered architecture like X86
> > >
> > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > configuration to abstract such dependency so that other
> > > weakly ordered architectures can reuse this infrastructure.
> >
> > Looks a bit clumsy.
> > Please try to follow this suggestion instead:
> > http://dpdk.org/ml/archives/dev/2015-October/025505.html
> 
> Make sense. Do we agree on a macro that is defined based upon
> RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?

Why do we need that macro at all?
Why just not have architecture specific macro as was discussed in that thread?

So for intel somewhere inside
lib/librte_eal/common/include/arch/x86/rte_atomic.h 

it would be:

#define rte_smp_wmb()	rte_compiler_barrier()

For arm inside lib/librte_eal/common/include/arch/x86/rte_atomic.h

#define rte_smp_wmb()	rte_wmb()

And so on.

I think it was already an attempt (not finished) to do similar stuff for ppc:
http://dpdk.org/dev/patchwork/patch/5884/

Konstantin

> 
> Jerin
> 
> >
> > Konstantin
> >
> > >
> > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > ---
> > >  config/common_bsdapp                         |  5 +++++
> > >  config/common_linuxapp                       |  5 +++++
> > >  config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
> > >  config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
> > >  lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
> > >  5 files changed, 32 insertions(+)
> > >
> > > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > > index b37dcf4..c8d1f63 100644
> > > --- a/config/common_bsdapp
> > > +++ b/config/common_bsdapp
> > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > >
> > >  #
> > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > +#
> > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > +
> > > +#
> > >  # Compile to share library
> > >  #
> > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > > index 0de43d5..d040a74 100644
> > > --- a/config/common_linuxapp
> > > +++ b/config/common_linuxapp
> > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > >
> > >  #
> > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > +#
> > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > +
> > > +#
> > >  # Compile to share library
> > >  #
> > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > index 6ea38a5..5289152 100644
> > > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > >  CONFIG_RTE_ARCH_ARM64=y
> > >  CONFIG_RTE_ARCH_64=y
> > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > >
> > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > >
> > > diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > index e8fccc7..79fa9e6 100644
> > > --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > >  CONFIG_RTE_ARCH_ARM64=y
> > >  CONFIG_RTE_ARCH_64=y
> > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > >
> > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > >
> > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > > index af68888..1ccd186 100644
> > > --- a/lib/librte_ring/rte_ring.h
> > > +++ b/lib/librte_ring/rte_ring.h
> > > @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > >
> > >  	/* write entries in ring */
> > >  	ENQUEUE_PTRS();
> > > +
> > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > >  	rte_compiler_barrier();
> > > +#else
> > > +	rte_wmb();
> > > +#endif
> > >
> > >  	/* if we exceed the watermark */
> > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > >
> > >  	/* write entries in ring */
> > >  	ENQUEUE_PTRS();
> > > +
> > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > >  	rte_compiler_barrier();
> > > +#else
> > > +	rte_wmb();
> > > +#endif
> > >
> > >  	/* if we exceed the watermark */
> > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
> > >
> > >  	/* copy in table */
> > >  	DEQUEUE_PTRS();
> > > +
> > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > >  	rte_compiler_barrier();
> > > +#else
> > > +	rte_rmb();
> > > +#endif
> > >
> > >  	/*
> > >  	 * If there are other dequeues in progress that preceded us,
> > > @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
> > >
> > >  	/* copy in table */
> > >  	DEQUEUE_PTRS();
> > > +
> > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > >  	rte_compiler_barrier();
> > > +#else
> > > +	rte_rmb();
> > > +#endif
> > >
> > >  	__RING_STAT_ADD(r, deq_success, n);
> > >  	r->cons.tail = cons_next;
> > > --
> > > 2.1.0
> >

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 16:28     ` Ananyev, Konstantin
@ 2015-11-03 16:53       ` Jerin Jacob
  2015-11-03 17:02         ` Richardson, Bruce
  2015-11-03 17:12         ` Ananyev, Konstantin
  0 siblings, 2 replies; 10+ messages in thread
From: Jerin Jacob @ 2015-11-03 16:53 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

On Tue, Nov 03, 2015 at 04:28:00PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Tuesday, November 03, 2015 4:19 PM
> > To: Ananyev, Konstantin
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > 
> > On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > Sent: Tuesday, November 03, 2015 3:52 PM
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > > >
> > > > rte_ring implementation needs explicit memory barrier
> > > > in weakly ordered architecture like ARM unlike
> > > > strongly ordered architecture like X86
> > > >
> > > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > configuration to abstract such dependency so that other
> > > > weakly ordered architectures can reuse this infrastructure.
> > >
> > > Looks a bit clumsy.
> > > Please try to follow this suggestion instead:
> > > http://dpdk.org/ml/archives/dev/2015-October/025505.html
> > 
> > Make sense. Do we agree on a macro that is defined based upon
> > RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?
> 
> Why do we need that macro at all?
> Why just not have architecture specific macro as was discussed in that thread?
> 
> So for intel somewhere inside
> lib/librte_eal/common/include/arch/x86/rte_atomic.h 
> 
> it would be:
> 
> #define rte_smp_wmb()	rte_compiler_barrier()
> 
> For arm inside lib/librte_eal/common/include/arch/x86/rte_atomic.h
> 
> #define rte_smp_wmb()	rte_wmb()

I am not sure about the other architecture but in armv8 device memory
(typically mapped through NIC PCIe BAR space) are strongly ordered.
So there is one more dimension to the equation(normal memory or device
memory).
IMO rte_smp_wmb() -> rte_wmb() mapping to deal with device memory may
not be correct on arm64 ?

Thoughts ?

> 
> And so on.
> 
> I think it was already an attempt (not finished) to do similar stuff for ppc:
> http://dpdk.org/dev/patchwork/patch/5884/
> 
> Konstantin
> 
> > 
> > Jerin
> > 
> > >
> > > Konstantin
> > >
> > > >
> > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > ---
> > > >  config/common_bsdapp                         |  5 +++++
> > > >  config/common_linuxapp                       |  5 +++++
> > > >  config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
> > > >  config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
> > > >  lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
> > > >  5 files changed, 32 insertions(+)
> > > >
> > > > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > > > index b37dcf4..c8d1f63 100644
> > > > --- a/config/common_bsdapp
> > > > +++ b/config/common_bsdapp
> > > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > > >
> > > >  #
> > > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > > +#
> > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > > +
> > > > +#
> > > >  # Compile to share library
> > > >  #
> > > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > > > index 0de43d5..d040a74 100644
> > > > --- a/config/common_linuxapp
> > > > +++ b/config/common_linuxapp
> > > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > > >
> > > >  #
> > > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > > +#
> > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > > +
> > > > +#
> > > >  # Compile to share library
> > > >  #
> > > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > index 6ea38a5..5289152 100644
> > > > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > > >  CONFIG_RTE_ARCH_ARM64=y
> > > >  CONFIG_RTE_ARCH_64=y
> > > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > > >
> > > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > > >
> > > > diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > index e8fccc7..79fa9e6 100644
> > > > --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > > >  CONFIG_RTE_ARCH_ARM64=y
> > > >  CONFIG_RTE_ARCH_64=y
> > > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > > >
> > > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > > >
> > > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > > > index af68888..1ccd186 100644
> > > > --- a/lib/librte_ring/rte_ring.h
> > > > +++ b/lib/librte_ring/rte_ring.h
> > > > @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > > >
> > > >  	/* write entries in ring */
> > > >  	ENQUEUE_PTRS();
> > > > +
> > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > >  	rte_compiler_barrier();
> > > > +#else
> > > > +	rte_wmb();
> > > > +#endif
> > > >
> > > >  	/* if we exceed the watermark */
> > > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > > @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > > >
> > > >  	/* write entries in ring */
> > > >  	ENQUEUE_PTRS();
> > > > +
> > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > >  	rte_compiler_barrier();
> > > > +#else
> > > > +	rte_wmb();
> > > > +#endif
> > > >
> > > >  	/* if we exceed the watermark */
> > > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > > @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
> > > >
> > > >  	/* copy in table */
> > > >  	DEQUEUE_PTRS();
> > > > +
> > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > >  	rte_compiler_barrier();
> > > > +#else
> > > > +	rte_rmb();
> > > > +#endif
> > > >
> > > >  	/*
> > > >  	 * If there are other dequeues in progress that preceded us,
> > > > @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
> > > >
> > > >  	/* copy in table */
> > > >  	DEQUEUE_PTRS();
> > > > +
> > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > >  	rte_compiler_barrier();
> > > > +#else
> > > > +	rte_rmb();
> > > > +#endif
> > > >
> > > >  	__RING_STAT_ADD(r, deq_success, n);
> > > >  	r->cons.tail = cons_next;
> > > > --
> > > > 2.1.0
> > >

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 16:53       ` Jerin Jacob
@ 2015-11-03 17:02         ` Richardson, Bruce
  2015-11-03 17:12         ` Ananyev, Konstantin
  1 sibling, 0 replies; 10+ messages in thread
From: Richardson, Bruce @ 2015-11-03 17:02 UTC (permalink / raw)
  To: Jerin Jacob, Ananyev, Konstantin; +Cc: dev



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> Sent: Tuesday, November 3, 2015 4:53 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce
> RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> 
> On Tue, Nov 03, 2015 at 04:28:00PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > Sent: Tuesday, November 03, 2015 4:19 PM
> > > To: Ananyev, Konstantin
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce
> > > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > >
> > > On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > > Sent: Tuesday, November 03, 2015 3:52 PM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce
> > > > > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > > > >
> > > > > rte_ring implementation needs explicit memory barrier in weakly
> > > > > ordered architecture like ARM unlike strongly ordered
> > > > > architecture like X86
> > > > >
> > > > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration to
> > > > > abstract such dependency so that other weakly ordered
> > > > > architectures can reuse this infrastructure.
> > > >
> > > > Looks a bit clumsy.
> > > > Please try to follow this suggestion instead:
> > > > http://dpdk.org/ml/archives/dev/2015-October/025505.html
> > >
> > > Make sense. Do we agree on a macro that is defined based upon
> > > RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?
> >
> > Why do we need that macro at all?
> > Why just not have architecture specific macro as was discussed in that
> thread?
> >
> > So for intel somewhere inside
> > lib/librte_eal/common/include/arch/x86/rte_atomic.h
> >
> > it would be:
> >
> > #define rte_smp_wmb()	rte_compiler_barrier()
> >
> > For arm inside lib/librte_eal/common/include/arch/x86/rte_atomic.h
> >
> > #define rte_smp_wmb()	rte_wmb()
> 
> I am not sure about the other architecture but in armv8 device memory
> (typically mapped through NIC PCIe BAR space) are strongly ordered.
> So there is one more dimension to the equation(normal memory or device
> memory).
> IMO rte_smp_wmb() -> rte_wmb() mapping to deal with device memory may not
> be correct on arm64 ?
> 
> Thoughts ?
> 
In cases like that I don't think barriers are needed on any platform so the proposed scheme will work fine. It's up the driver writer to know about when they are writing to device BARs or not.

/Bruce

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 16:53       ` Jerin Jacob
  2015-11-03 17:02         ` Richardson, Bruce
@ 2015-11-03 17:12         ` Ananyev, Konstantin
  2015-11-04  3:33           ` Jerin Jacob
  1 sibling, 1 reply; 10+ messages in thread
From: Ananyev, Konstantin @ 2015-11-03 17:12 UTC (permalink / raw)
  To: Jerin Jacob; +Cc: dev



> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Tuesday, November 03, 2015 4:53 PM
> To: Ananyev, Konstantin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> 
> On Tue, Nov 03, 2015 at 04:28:00PM +0000, Ananyev, Konstantin wrote:
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > Sent: Tuesday, November 03, 2015 4:19 PM
> > > To: Ananyev, Konstantin
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > >
> > > On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > > Sent: Tuesday, November 03, 2015 3:52 PM
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > > > >
> > > > > rte_ring implementation needs explicit memory barrier
> > > > > in weakly ordered architecture like ARM unlike
> > > > > strongly ordered architecture like X86
> > > > >
> > > > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > > configuration to abstract such dependency so that other
> > > > > weakly ordered architectures can reuse this infrastructure.
> > > >
> > > > Looks a bit clumsy.
> > > > Please try to follow this suggestion instead:
> > > > http://dpdk.org/ml/archives/dev/2015-October/025505.html
> > >
> > > Make sense. Do we agree on a macro that is defined based upon
> > > RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?
> >
> > Why do we need that macro at all?
> > Why just not have architecture specific macro as was discussed in that thread?
> >
> > So for intel somewhere inside
> > lib/librte_eal/common/include/arch/x86/rte_atomic.h
> >
> > it would be:
> >
> > #define rte_smp_wmb()	rte_compiler_barrier()
> >
> > For arm inside lib/librte_eal/common/include/arch/x86/rte_atomic.h
> >
> > #define rte_smp_wmb()	rte_wmb()
> 
> I am not sure about the other architecture but in armv8 device memory
> (typically mapped through NIC PCIe BAR space) are strongly ordered.
> So there is one more dimension to the equation(normal memory or device
> memory).
> IMO rte_smp_wmb() -> rte_wmb() mapping to deal with device memory may
> not be correct on arm64 ?

I thought we are talking now for multi-processor case no?
For that would be: rte_smp_... set of macros.
Similar to what linux guys have. 
Konstantin

> 
> Thoughts ?




> 
> >
> > And so on.
> >
> > I think it was already an attempt (not finished) to do similar stuff for ppc:
> > http://dpdk.org/dev/patchwork/patch/5884/
> >
> > Konstantin
> >
> > >
> > > Jerin
> > >
> > > >
> > > > Konstantin
> > > >
> > > > >
> > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > > ---
> > > > >  config/common_bsdapp                         |  5 +++++
> > > > >  config/common_linuxapp                       |  5 +++++
> > > > >  config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
> > > > >  config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
> > > > >  lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
> > > > >  5 files changed, 32 insertions(+)
> > > > >
> > > > > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > > > > index b37dcf4..c8d1f63 100644
> > > > > --- a/config/common_bsdapp
> > > > > +++ b/config/common_bsdapp
> > > > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > > > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > > > >
> > > > >  #
> > > > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > > > +#
> > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > > > +
> > > > > +#
> > > > >  # Compile to share library
> > > > >  #
> > > > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > > > > index 0de43d5..d040a74 100644
> > > > > --- a/config/common_linuxapp
> > > > > +++ b/config/common_linuxapp
> > > > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > > > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > > > >
> > > > >  #
> > > > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > > > +#
> > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > > > +
> > > > > +#
> > > > >  # Compile to share library
> > > > >  #
> > > > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > > index 6ea38a5..5289152 100644
> > > > > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > > > >  CONFIG_RTE_ARCH_ARM64=y
> > > > >  CONFIG_RTE_ARCH_64=y
> > > > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > > > >
> > > > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > > > >
> > > > > diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > > index e8fccc7..79fa9e6 100644
> > > > > --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > > +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > > > >  CONFIG_RTE_ARCH_ARM64=y
> > > > >  CONFIG_RTE_ARCH_64=y
> > > > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > > > >
> > > > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > > > >
> > > > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > > > > index af68888..1ccd186 100644
> > > > > --- a/lib/librte_ring/rte_ring.h
> > > > > +++ b/lib/librte_ring/rte_ring.h
> > > > > @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > > > >
> > > > >  	/* write entries in ring */
> > > > >  	ENQUEUE_PTRS();
> > > > > +
> > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > >  	rte_compiler_barrier();
> > > > > +#else
> > > > > +	rte_wmb();
> > > > > +#endif
> > > > >
> > > > >  	/* if we exceed the watermark */
> > > > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > > > @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > > > >
> > > > >  	/* write entries in ring */
> > > > >  	ENQUEUE_PTRS();
> > > > > +
> > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > >  	rte_compiler_barrier();
> > > > > +#else
> > > > > +	rte_wmb();
> > > > > +#endif
> > > > >
> > > > >  	/* if we exceed the watermark */
> > > > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > > > @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
> > > > >
> > > > >  	/* copy in table */
> > > > >  	DEQUEUE_PTRS();
> > > > > +
> > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > >  	rte_compiler_barrier();
> > > > > +#else
> > > > > +	rte_rmb();
> > > > > +#endif
> > > > >
> > > > >  	/*
> > > > >  	 * If there are other dequeues in progress that preceded us,
> > > > > @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
> > > > >
> > > > >  	/* copy in table */
> > > > >  	DEQUEUE_PTRS();
> > > > > +
> > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > >  	rte_compiler_barrier();
> > > > > +#else
> > > > > +	rte_rmb();
> > > > > +#endif
> > > > >
> > > > >  	__RING_STAT_ADD(r, deq_success, n);
> > > > >  	r->cons.tail = cons_next;
> > > > > --
> > > > > 2.1.0
> > > >

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
  2015-11-03 17:12         ` Ananyev, Konstantin
@ 2015-11-04  3:33           ` Jerin Jacob
  0 siblings, 0 replies; 10+ messages in thread
From: Jerin Jacob @ 2015-11-04  3:33 UTC (permalink / raw)
  To: Ananyev, Konstantin; +Cc: dev

On Tue, Nov 03, 2015 at 05:12:21PM +0000, Ananyev, Konstantin wrote:
> 
> 
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Tuesday, November 03, 2015 4:53 PM
> > To: Ananyev, Konstantin
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > 
> > On Tue, Nov 03, 2015 at 04:28:00PM +0000, Ananyev, Konstantin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > > Sent: Tuesday, November 03, 2015 4:19 PM
> > > > To: Ananyev, Konstantin
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > > >
> > > > On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> > > > > > Sent: Tuesday, November 03, 2015 3:52 PM
> > > > > > To: dev@dpdk.org
> > > > > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter
> > > > > >
> > > > > > rte_ring implementation needs explicit memory barrier
> > > > > > in weakly ordered architecture like ARM unlike
> > > > > > strongly ordered architecture like X86
> > > > > >
> > > > > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > > > configuration to abstract such dependency so that other
> > > > > > weakly ordered architectures can reuse this infrastructure.
> > > > >
> > > > > Looks a bit clumsy.
> > > > > Please try to follow this suggestion instead:
> > > > > http://dpdk.org/ml/archives/dev/2015-October/025505.html
> > > >
> > > > Make sense. Do we agree on a macro that is defined based upon
> > > > RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ?
> > >
> > > Why do we need that macro at all?
> > > Why just not have architecture specific macro as was discussed in that thread?
> > >
> > > So for intel somewhere inside
> > > lib/librte_eal/common/include/arch/x86/rte_atomic.h
> > >
> > > it would be:
> > >
> > > #define rte_smp_wmb()	rte_compiler_barrier()
> > >
> > > For arm inside lib/librte_eal/common/include/arch/x86/rte_atomic.h
> > >
> > > #define rte_smp_wmb()	rte_wmb()
> > 
> > I am not sure about the other architecture but in armv8 device memory
> > (typically mapped through NIC PCIe BAR space) are strongly ordered.
> > So there is one more dimension to the equation(normal memory or device
> > memory).
> > IMO rte_smp_wmb() -> rte_wmb() mapping to deal with device memory may
> > not be correct on arm64 ?
> 
> I thought we are talking now for multi-processor case no?
> For that would be: rte_smp_... set of macros.
> Similar to what linux guys have. 

make sense. I will send out RFC patch for the defintion and
implementation of rte_smp_wb(),rte_smp_wmb(), and rte_smp_rmb()

Jerin

> Konstantin
> 
> > 
> > Thoughts ?
> 
> 
> 
> 
> > 
> > >
> > > And so on.
> > >
> > > I think it was already an attempt (not finished) to do similar stuff for ppc:
> > > http://dpdk.org/dev/patchwork/patch/5884/
> > >
> > > Konstantin
> > >
> > > >
> > > > Jerin
> > > >
> > > > >
> > > > > Konstantin
> > > > >
> > > > > >
> > > > > > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > > > > ---
> > > > > >  config/common_bsdapp                         |  5 +++++
> > > > > >  config/common_linuxapp                       |  5 +++++
> > > > > >  config/defconfig_arm64-armv8a-linuxapp-gcc   |  1 +
> > > > > >  config/defconfig_arm64-thunderx-linuxapp-gcc |  1 +
> > > > > >  lib/librte_ring/rte_ring.h                   | 20 ++++++++++++++++++++
> > > > > >  5 files changed, 32 insertions(+)
> > > > > >
> > > > > > diff --git a/config/common_bsdapp b/config/common_bsdapp
> > > > > > index b37dcf4..c8d1f63 100644
> > > > > > --- a/config/common_bsdapp
> > > > > > +++ b/config/common_bsdapp
> > > > > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > > > > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > > > > >
> > > > > >  #
> > > > > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > > > > +#
> > > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > > > > +
> > > > > > +#
> > > > > >  # Compile to share library
> > > > > >  #
> > > > > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > > diff --git a/config/common_linuxapp b/config/common_linuxapp
> > > > > > index 0de43d5..d040a74 100644
> > > > > > --- a/config/common_linuxapp
> > > > > > +++ b/config/common_linuxapp
> > > > > > @@ -79,6 +79,11 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> > > > > >  CONFIG_RTE_ARCH_STRICT_ALIGN=n
> > > > > >
> > > > > >  #
> > > > > > +# Machine has strongly-ordered memory operations on normal memory like x86
> > > > > > +#
> > > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=y
> > > > > > +
> > > > > > +#
> > > > > >  # Compile to share library
> > > > > >  #
> > > > > >  CONFIG_RTE_BUILD_SHARED_LIB=n
> > > > > > diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > > > index 6ea38a5..5289152 100644
> > > > > > --- a/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > > > +++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
> > > > > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > > > > >  CONFIG_RTE_ARCH_ARM64=y
> > > > > >  CONFIG_RTE_ARCH_64=y
> > > > > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > > > > >
> > > > > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > > > > >
> > > > > > diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > > > index e8fccc7..79fa9e6 100644
> > > > > > --- a/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > > > +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
> > > > > > @@ -37,6 +37,7 @@ CONFIG_RTE_ARCH="arm64"
> > > > > >  CONFIG_RTE_ARCH_ARM64=y
> > > > > >  CONFIG_RTE_ARCH_64=y
> > > > > >  CONFIG_RTE_ARCH_ARM_NEON=y
> > > > > > +CONFIG_RTE_ARCH_STRONGLY_ORDERED_MEM_OPS=n
> > > > > >
> > > > > >  CONFIG_RTE_FORCE_INTRINSICS=y
> > > > > >
> > > > > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > > > > > index af68888..1ccd186 100644
> > > > > > --- a/lib/librte_ring/rte_ring.h
> > > > > > +++ b/lib/librte_ring/rte_ring.h
> > > > > > @@ -457,7 +457,12 @@ __rte_ring_mp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > > > > >
> > > > > >  	/* write entries in ring */
> > > > > >  	ENQUEUE_PTRS();
> > > > > > +
> > > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > > >  	rte_compiler_barrier();
> > > > > > +#else
> > > > > > +	rte_wmb();
> > > > > > +#endif
> > > > > >
> > > > > >  	/* if we exceed the watermark */
> > > > > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > > > > @@ -552,7 +557,12 @@ __rte_ring_sp_do_enqueue(struct rte_ring *r, void * const *obj_table,
> > > > > >
> > > > > >  	/* write entries in ring */
> > > > > >  	ENQUEUE_PTRS();
> > > > > > +
> > > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > > >  	rte_compiler_barrier();
> > > > > > +#else
> > > > > > +	rte_wmb();
> > > > > > +#endif
> > > > > >
> > > > > >  	/* if we exceed the watermark */
> > > > > >  	if (unlikely(((mask + 1) - free_entries + n) > r->prod.watermark)) {
> > > > > > @@ -643,7 +653,12 @@ __rte_ring_mc_do_dequeue(struct rte_ring *r, void **obj_table,
> > > > > >
> > > > > >  	/* copy in table */
> > > > > >  	DEQUEUE_PTRS();
> > > > > > +
> > > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > > >  	rte_compiler_barrier();
> > > > > > +#else
> > > > > > +	rte_rmb();
> > > > > > +#endif
> > > > > >
> > > > > >  	/*
> > > > > >  	 * If there are other dequeues in progress that preceded us,
> > > > > > @@ -727,7 +742,12 @@ __rte_ring_sc_do_dequeue(struct rte_ring *r, void **obj_table,
> > > > > >
> > > > > >  	/* copy in table */
> > > > > >  	DEQUEUE_PTRS();
> > > > > > +
> > > > > > +#ifdef RTE_ARCH_STRONGLY_ORDERED_MEM_OPS
> > > > > >  	rte_compiler_barrier();
> > > > > > +#else
> > > > > > +	rte_rmb();
> > > > > > +#endif
> > > > > >
> > > > > >  	__RING_STAT_ADD(r, deq_success, n);
> > > > > >  	r->cons.tail = cons_next;
> > > > > > --
> > > > > > 2.1.0
> > > > >

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2015-11-04  3:34 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-03 15:52 [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter Jerin Jacob
2015-11-03 15:57 ` simon barber
2015-11-03 15:57 ` Ananyev, Konstantin
2015-11-03 16:18   ` Jerin Jacob
2015-11-03 16:24     ` Richardson, Bruce
2015-11-03 16:28     ` Ananyev, Konstantin
2015-11-03 16:53       ` Jerin Jacob
2015-11-03 17:02         ` Richardson, Bruce
2015-11-03 17:12         ` Ananyev, Konstantin
2015-11-04  3:33           ` Jerin Jacob

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).