* [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
@ 2019-03-18 12:58 Dekel Peled
2019-03-19 3:24 ` Chao Zhu
2019-03-28 22:50 ` Thomas Monjalon
0 siblings, 2 replies; 8+ messages in thread
From: Dekel Peled @ 2019-03-18 12:58 UTC (permalink / raw)
To: chaozhu; +Cc: yskoh, shahafs, dev, orika, thomas, dekelp, stable
From previous patch description: "to improve performance on PPC64,
use light weight sync instruction instead of sync instruction."
Excerpt from IBM doc [1], section "Memory barrier instructions":
"The second form of the sync instruction is light-weight sync,
or lwsync.
This form is used to control ordering for storage accesses to system
memory only. It does not create a memory barrier for accesses to
device memory."
This patch removes the use of lwsync, so calls to rte_wmb() and
rte_rmb() will provide correct memory barrier to ensure order of
accesses to system memory and device memory.
[1] https://www.ibm.com/developerworks/systems/articles/powerpc.html
Fixes: d23a6bd04d72 ("eal/ppc: fix memory barrier for IBM POWER")
Cc: stable@dpdk.org
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
---
lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
index ce38350..797381c 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
@@ -63,11 +63,7 @@
* Guarantees that the STORE operations generated before the barrier
* occur before the STORE operations generated after.
*/
-#ifdef RTE_ARCH_64
-#define rte_wmb() asm volatile("lwsync" : : : "memory")
-#else
#define rte_wmb() asm volatile("sync" : : : "memory")
-#endif
/**
* Read memory barrier.
@@ -75,11 +71,7 @@
* Guarantees that the LOAD operations generated before the barrier
* occur before the LOAD operations generated after.
*/
-#ifdef RTE_ARCH_64
-#define rte_rmb() asm volatile("lwsync" : : : "memory")
-#else
#define rte_rmb() asm volatile("sync" : : : "memory")
-#endif
#define rte_smp_mb() rte_mb()
--
1.8.3.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
2019-03-18 12:58 [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER Dekel Peled
@ 2019-03-19 3:24 ` Chao Zhu
2019-03-19 10:05 ` Dekel Peled
2019-03-28 22:50 ` Thomas Monjalon
1 sibling, 1 reply; 8+ messages in thread
From: Chao Zhu @ 2019-03-19 3:24 UTC (permalink / raw)
To: 'Dekel Peled'; +Cc: yskoh, shahafs, dev, orika, thomas, stable
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2498 bytes --]
Dekel£¬
To control the memory order for device memory, I think you should use
rte_io_mb() instead of rte_mb(). This will generate correct result. rte_wmb()
is used for system memory.
> -----Original Message-----
> From: Dekel Peled <dekelp@mellanox.com>
> Sent: Monday, March 18, 2019 8:58 PM
> To: chaozhu@linux.vnet.ibm.com
> Cc: yskoh@mellanox.com; shahafs@mellanox.com; dev@dpdk.org;
> orika@mellanox.com; thomas@monjalon.net; dekelp@mellanox.com;
> stable@dpdk.org
> Subject: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
>
> From previous patch description: "to improve performance on PPC64, use light
> weight sync instruction instead of sync instruction."
>
> Excerpt from IBM doc [1], section "Memory barrier instructions":
> "The second form of the sync instruction is light-weight sync, or lwsync.
> This form is used to control ordering for storage accesses to system memory
> only. It does not create a memory barrier for accesses to device memory."
>
> This patch removes the use of lwsync, so calls to rte_wmb() and
> rte_rmb() will provide correct memory barrier to ensure order of accesses to
> system memory and device memory.
>
> [1] https://www.ibm.com/developerworks/systems/articles/powerpc.html
>
> Fixes: d23a6bd04d72 ("eal/ppc: fix memory barrier for IBM POWER")
> Cc: stable@dpdk.org
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> ---
> lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> index ce38350..797381c 100644
> --- a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> @@ -63,11 +63,7 @@
> * Guarantees that the STORE operations generated before the barrier
> * occur before the STORE operations generated after.
> */
> -#ifdef RTE_ARCH_64
> -#define rte_wmb() asm volatile("lwsync" : : : "memory")
> -#else
> #define rte_wmb() asm volatile("sync" : : : "memory")
> -#endif
>
> /**
> * Read memory barrier.
> @@ -75,11 +71,7 @@
> * Guarantees that the LOAD operations generated before the barrier
> * occur before the LOAD operations generated after.
> */
> -#ifdef RTE_ARCH_64
> -#define rte_rmb() asm volatile("lwsync" : : : "memory")
> -#else
> #define rte_rmb() asm volatile("sync" : : : "memory")
> -#endif
>
> #define rte_smp_mb() rte_mb()
>
> --
> 1.8.3.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
2019-03-19 3:24 ` Chao Zhu
@ 2019-03-19 10:05 ` Dekel Peled
2019-03-19 11:14 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Dekel Peled @ 2019-03-19 10:05 UTC (permalink / raw)
To: Chao Zhu
Cc: Yongseok Koh, Shahaf Shuler, dev, Ori Kam, Thomas Monjalon, stable
Hi,
For ppc, rte_io_mb() is defined as rte_mb(), which is defined as asm sync.
According to comments in arch/ppc_64/rte_atomic.h, rte_wmb() and rte_rmb() are the same as rte_mb(), for store and load respectively.
My patch propose to define rte_wmb() and rte_rmb() as asm sync, like rte_mb(), since using lwsync is incorrect for them.
Regards,
Dekel
> -----Original Message-----
> From: Chao Zhu <chaozhu@linux.vnet.ibm.com>
> Sent: Tuesday, March 19, 2019 5:24 AM
> To: Dekel Peled <dekelp@mellanox.com>
> Cc: Yongseok Koh <yskoh@mellanox.com>; Shahaf Shuler
> <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam <orika@mellanox.com>;
> Thomas Monjalon <thomas@monjalon.net>; stable@dpdk.org
> Subject: RE: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
>
> Dekel£¬
>
> To control the memory order for device memory, I think you should use
> rte_io_mb() instead of rte_mb(). This will generate correct result. rte_wmb()
> is used for system memory.
>
> > -----Original Message-----
> > From: Dekel Peled <dekelp@mellanox.com>
> > Sent: Monday, March 18, 2019 8:58 PM
> > To: chaozhu@linux.vnet.ibm.com
> > Cc: yskoh@mellanox.com; shahafs@mellanox.com; dev@dpdk.org;
> > orika@mellanox.com; thomas@monjalon.net; dekelp@mellanox.com;
> > stable@dpdk.org
> > Subject: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
> >
> > From previous patch description: "to improve performance on PPC64, use
> > light weight sync instruction instead of sync instruction."
> >
> > Excerpt from IBM doc [1], section "Memory barrier instructions":
> > "The second form of the sync instruction is light-weight sync, or lwsync.
> > This form is used to control ordering for storage accesses to system
> > memory only. It does not create a memory barrier for accesses to device
> memory."
> >
> > This patch removes the use of lwsync, so calls to rte_wmb() and
> > rte_rmb() will provide correct memory barrier to ensure order of
> > accesses to system memory and device memory.
> >
> > [1]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .
> >
> ibm.com%2Fdeveloperworks%2Fsystems%2Farticles%2Fpowerpc.html&
> ;data=
> >
> 02%7C01%7Cdekelp%40mellanox.com%7C381426b6b9d042f776fa08d6ac1a5d
> c5%7Ca
> >
> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636885626593364016&am
> p;sdata
> >
> =wFYTcFX2A%2BMdtQMgtojTAtUOzqds7U5pypNS%2F2SoXUM%3D&re
> served=0
> >
> > Fixes: d23a6bd04d72 ("eal/ppc: fix memory barrier for IBM POWER")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > ---
> > lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > index ce38350..797381c 100644
> > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > @@ -63,11 +63,7 @@
> > * Guarantees that the STORE operations generated before the barrier
> > * occur before the STORE operations generated after.
> > */
> > -#ifdef RTE_ARCH_64
> > -#define rte_wmb() asm volatile("lwsync" : : : "memory")
> > -#else
> > #define rte_wmb() asm volatile("sync" : : : "memory")
> > -#endif
> >
> > /**
> > * Read memory barrier.
> > @@ -75,11 +71,7 @@
> > * Guarantees that the LOAD operations generated before the barrier
> > * occur before the LOAD operations generated after.
> > */
> > -#ifdef RTE_ARCH_64
> > -#define rte_rmb() asm volatile("lwsync" : : : "memory")
> > -#else
> > #define rte_rmb() asm volatile("sync" : : : "memory")
> > -#endif
> >
> > #define rte_smp_mb() rte_mb()
> >
> > --
> > 1.8.3.1
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
2019-03-19 10:05 ` Dekel Peled
@ 2019-03-19 11:14 ` Thomas Monjalon
2019-03-19 19:42 ` Shahaf Shuler
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2019-03-19 11:14 UTC (permalink / raw)
To: Dekel Peled, Chao Zhu; +Cc: Yongseok Koh, Shahaf Shuler, dev, Ori Kam, stable
Guys, please let's avoid top-post.
You are both not replying to each other:
1/ Dekel mentioned the IBM doc but Chao did not argue about
the lack of IO protection with lwsync.
We assume that rte_mb should protect any access including IO.
2/ Chao asked about the semantic of the barrier used in mlx5 code,
but Dekel did not reply about the semantic: are we protecting
IO or general memory access?
19/03/2019 11:05, Dekel Peled:
> Hi,
>
> For ppc, rte_io_mb() is defined as rte_mb(), which is defined as asm sync.
> According to comments in arch/ppc_64/rte_atomic.h, rte_wmb() and rte_rmb() are the same as rte_mb(), for store and load respectively.
> My patch propose to define rte_wmb() and rte_rmb() as asm sync, like rte_mb(), since using lwsync is incorrect for them.
>
> Regards,
> Dekel
>
> > -----Original Message-----
> > From: Chao Zhu <chaozhu@linux.vnet.ibm.com>
> > Sent: Tuesday, March 19, 2019 5:24 AM
> > To: Dekel Peled <dekelp@mellanox.com>
> > Cc: Yongseok Koh <yskoh@mellanox.com>; Shahaf Shuler
> > <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam <orika@mellanox.com>;
> > Thomas Monjalon <thomas@monjalon.net>; stable@dpdk.org
> > Subject: RE: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
> >
> > Dekel£¬
> >
> > To control the memory order for device memory, I think you should use
> > rte_io_mb() instead of rte_mb(). This will generate correct result. rte_wmb()
> > is used for system memory.
> >
> > > -----Original Message-----
> > > From: Dekel Peled <dekelp@mellanox.com>
> > > Sent: Monday, March 18, 2019 8:58 PM
> > > To: chaozhu@linux.vnet.ibm.com
> > > Cc: yskoh@mellanox.com; shahafs@mellanox.com; dev@dpdk.org;
> > > orika@mellanox.com; thomas@monjalon.net; dekelp@mellanox.com;
> > > stable@dpdk.org
> > > Subject: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
> > >
> > > From previous patch description: "to improve performance on PPC64, use
> > > light weight sync instruction instead of sync instruction."
> > >
> > > Excerpt from IBM doc [1], section "Memory barrier instructions":
> > > "The second form of the sync instruction is light-weight sync, or lwsync.
> > > This form is used to control ordering for storage accesses to system
> > > memory only. It does not create a memory barrier for accesses to device
> > memory."
> > >
> > > This patch removes the use of lwsync, so calls to rte_wmb() and
> > > rte_rmb() will provide correct memory barrier to ensure order of
> > > accesses to system memory and device memory.
> > >
> > > [1]
> > >
> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> > .
> > >
> > ibm.com%2Fdeveloperworks%2Fsystems%2Farticles%2Fpowerpc.html&
> > ;data=
> > >
> > 02%7C01%7Cdekelp%40mellanox.com%7C381426b6b9d042f776fa08d6ac1a5d
> > c5%7Ca
> > >
> > 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636885626593364016&am
> > p;sdata
> > >
> > =wFYTcFX2A%2BMdtQMgtojTAtUOzqds7U5pypNS%2F2SoXUM%3D&re
> > served=0
> > >
> > > Fixes: d23a6bd04d72 ("eal/ppc: fix memory barrier for IBM POWER")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > > ---
> > > lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h | 8 --------
> > > 1 file changed, 8 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > index ce38350..797381c 100644
> > > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > @@ -63,11 +63,7 @@
> > > * Guarantees that the STORE operations generated before the barrier
> > > * occur before the STORE operations generated after.
> > > */
> > > -#ifdef RTE_ARCH_64
> > > -#define rte_wmb() asm volatile("lwsync" : : : "memory")
> > > -#else
> > > #define rte_wmb() asm volatile("sync" : : : "memory")
> > > -#endif
> > >
> > > /**
> > > * Read memory barrier.
> > > @@ -75,11 +71,7 @@
> > > * Guarantees that the LOAD operations generated before the barrier
> > > * occur before the LOAD operations generated after.
> > > */
> > > -#ifdef RTE_ARCH_64
> > > -#define rte_rmb() asm volatile("lwsync" : : : "memory")
> > > -#else
> > > #define rte_rmb() asm volatile("sync" : : : "memory")
> > > -#endif
> > >
> > > #define rte_smp_mb() rte_mb()
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
2019-03-19 11:14 ` Thomas Monjalon
@ 2019-03-19 19:42 ` Shahaf Shuler
2019-03-19 20:45 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Shahaf Shuler @ 2019-03-19 19:42 UTC (permalink / raw)
To: Thomas Monjalon, Dekel Peled, Chao Zhu; +Cc: Yongseok Koh, dev, Ori Kam, stable
Tuesday, March 19, 2019 1:15 PM, Thomas Monjalon:
> Subject: Re: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
>
> Guys, please let's avoid top-post.
>
> You are both not replying to each other:
>
> 1/ Dekel mentioned the IBM doc but Chao did not argue about the lack of IO
> protection with lwsync.
> We assume that rte_mb should protect any access including IO.
>
> 2/ Chao asked about the semantic of the barrier used in mlx5 code, but Dekel
> did not reply about the semantic: are we protecting IO or general memory
> access?
In mlx5 code we want to sync between two different writes:
1. write to system memory (RAM)
2. write to MMIO memory (device)
We need #1 to be visible on host memory before #2 is committed to NIC.
We want to have a single type of barrier which will translate to the correct assembly based on the system arch, and in addition we want it light-weight as possible.
So far, when not running on power, we used the rte_wmb for that. On x86 and ARM systems it provided the needed guarantees.
It is also mentioned in the barrier doxygen on ARM arch:
"
Write memory barrier.
Guarantees that the STORE operations generated before the barrier
occur before the STORE operations generated after.
"
It doesn't restrict to store to system memory only.
w/ power is on somewhat different and in fact rte_mb is required. It obviously miss the point of those barrier if we will need to use a different barrier based on the system arch.
We need to align the definition of the different barriers in DPDK:
1. need a clear documentation of each. this should be global and not part of the specific implementation on each arch.
2. either modify ppc rte_wmb to match ARM and x86 ones or to define a new type of barrier which will sync between both I/O and stores to systems memory.
>
>
> 19/03/2019 11:05, Dekel Peled:
> > Hi,
> >
> > For ppc, rte_io_mb() is defined as rte_mb(), which is defined as asm sync.
> > According to comments in arch/ppc_64/rte_atomic.h, rte_wmb() and
> rte_rmb() are the same as rte_mb(), for store and load respectively.
> > My patch propose to define rte_wmb() and rte_rmb() as asm sync, like
> rte_mb(), since using lwsync is incorrect for them.
> >
> > Regards,
> > Dekel
> >
> > > -----Original Message-----
> > > From: Chao Zhu <chaozhu@linux.vnet.ibm.com>
> > > Sent: Tuesday, March 19, 2019 5:24 AM
> > > To: Dekel Peled <dekelp@mellanox.com>
> > > Cc: Yongseok Koh <yskoh@mellanox.com>; Shahaf Shuler
> > > <shahafs@mellanox.com>; dev@dpdk.org; Ori Kam
> <orika@mellanox.com>;
> > > Thomas Monjalon <thomas@monjalon.net>; stable@dpdk.org
> > > Subject: RE: [PATCH] eal/ppc: remove fix of memory barrier for IBM
> > > POWER
> > >
> > > Dekel£¬
> > >
> > > To control the memory order for device memory, I think you should
> > > use
> > > rte_io_mb() instead of rte_mb(). This will generate correct result.
> > > rte_wmb() is used for system memory.
> > >
> > > > -----Original Message-----
> > > > From: Dekel Peled <dekelp@mellanox.com>
> > > > Sent: Monday, March 18, 2019 8:58 PM
> > > > To: chaozhu@linux.vnet.ibm.com
> > > > Cc: yskoh@mellanox.com; shahafs@mellanox.com; dev@dpdk.org;
> > > > orika@mellanox.com; thomas@monjalon.net; dekelp@mellanox.com;
> > > > stable@dpdk.org
> > > > Subject: [PATCH] eal/ppc: remove fix of memory barrier for IBM
> > > > POWER
> > > >
> > > > From previous patch description: "to improve performance on PPC64,
> > > > use light weight sync instruction instead of sync instruction."
> > > >
> > > > Excerpt from IBM doc [1], section "Memory barrier instructions":
> > > > "The second form of the sync instruction is light-weight sync, or lwsync.
> > > > This form is used to control ordering for storage accesses to
> > > > system memory only. It does not create a memory barrier for
> > > > accesses to device
> > > memory."
> > > >
> > > > This patch removes the use of lwsync, so calls to rte_wmb() and
> > > > rte_rmb() will provide correct memory barrier to ensure order of
> > > > accesses to system memory and device memory.
> > > >
> > > > [1]
> > > >
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w
> > > .
> > > >
> > >
> ibm.com%2Fdeveloperworks%2Fsystems%2Farticles%2Fpowerpc.html&
> > > ;data=
> > > >
> > >
> 02%7C01%7Cdekelp%40mellanox.com%7C381426b6b9d042f776fa08d6ac1a5d
> > > c5%7Ca
> > > >
> > >
> 652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636885626593364016&am
> > > p;sdata
> > > >
> > >
> =wFYTcFX2A%2BMdtQMgtojTAtUOzqds7U5pypNS%2F2SoXUM%3D&re
> > > served=0
> > > >
> > > > Fixes: d23a6bd04d72 ("eal/ppc: fix memory barrier for IBM POWER")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > > > ---
> > > > lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h | 8
> > > > --------
> > > > 1 file changed, 8 deletions(-)
> > > >
> > > > diff --git
> > > > a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > > b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > > index ce38350..797381c 100644
> > > > --- a/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > > +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h
> > > > @@ -63,11 +63,7 @@
> > > > * Guarantees that the STORE operations generated before the barrier
> > > > * occur before the STORE operations generated after.
> > > > */
> > > > -#ifdef RTE_ARCH_64
> > > > -#define rte_wmb() asm volatile("lwsync" : : : "memory")
> > > > -#else
> > > > #define rte_wmb() asm volatile("sync" : : : "memory")
> > > > -#endif
> > > >
> > > > /**
> > > > * Read memory barrier.
> > > > @@ -75,11 +71,7 @@
> > > > * Guarantees that the LOAD operations generated before the barrier
> > > > * occur before the LOAD operations generated after.
> > > > */
> > > > -#ifdef RTE_ARCH_64
> > > > -#define rte_rmb() asm volatile("lwsync" : : : "memory")
> > > > -#else
> > > > #define rte_rmb() asm volatile("sync" : : : "memory")
> > > > -#endif
> > > >
> > > > #define rte_smp_mb() rte_mb()
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
2019-03-19 19:42 ` Shahaf Shuler
@ 2019-03-19 20:45 ` Thomas Monjalon
[not found] ` <OF129065AB.1B264FB9-ON882583C3.00792656-882583C3.007C9172@notes.na.collabserv.com>
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2019-03-19 20:45 UTC (permalink / raw)
To: Shahaf Shuler
Cc: Dekel Peled, Chao Zhu, Yongseok Koh, dev, Ori Kam, stable, pradeep
19/03/2019 20:42, Shahaf Shuler:
> Tuesday, March 19, 2019 1:15 PM, Thomas Monjalon:
> > Subject: Re: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
> >
> > Guys, please let's avoid top-post.
> >
> > You are both not replying to each other:
> >
> > 1/ Dekel mentioned the IBM doc but Chao did not argue about the lack of IO
> > protection with lwsync.
> > We assume that rte_mb should protect any access including IO.
> >
> > 2/ Chao asked about the semantic of the barrier used in mlx5 code, but Dekel
> > did not reply about the semantic: are we protecting IO or general memory
> > access?
>
> In mlx5 code we want to sync between two different writes:
> 1. write to system memory (RAM)
> 2. write to MMIO memory (device)
>
> We need #1 to be visible on host memory before #2 is committed to NIC.
> We want to have a single type of barrier which will translate to the correct assembly based on the system arch, and in addition we want it light-weight as possible.
>
> So far, when not running on power, we used the rte_wmb for that. On x86 and ARM systems it provided the needed guarantees.
> It is also mentioned in the barrier doxygen on ARM arch:
> "
> Write memory barrier.
>
> Guarantees that the STORE operations generated before the barrier
> occur before the STORE operations generated after.
> "
>
> It doesn't restrict to store to system memory only.
> w/ power is on somewhat different and in fact rte_mb is required. It obviously miss the point of those barrier if we will need to use a different barrier based on the system arch.
>
> We need to align the definition of the different barriers in DPDK:
> 1. need a clear documentation of each. this should be global and not part of the specific implementation on each arch.
The global definition is in lib/librte_eal/common/include/generic/rte_atomic.h
There are some copy/paste in Arm32 and PPC that I will remove.
> 2. either modify ppc rte_wmb to match ARM and x86 ones or to define a new type of barrier which will sync between both I/O and stores to systems memory.
The basic memory barrier of DPDK does not mention
a difference between I/O and system memory.
It is not explicit (yet) but I assume it is protecting both.
So, in my opinion, we need to make it explicit in the doc,
and fix the PPC implementation to comply with this definition.
Anyway, I don't see any significant effort from IBM to move from
the alpha support stage to a real Open Source support.
PS: sending a mail every two months, to promise improvements, is not enough!
-----------------
> > 19/03/2019 11:05, Dekel Peled:
> > > Hi,
> > >
> > > For ppc, rte_io_mb() is defined as rte_mb(), which is defined as asm sync.
> > > According to comments in arch/ppc_64/rte_atomic.h, rte_wmb() and
> > rte_rmb() are the same as rte_mb(), for store and load respectively.
> > > My patch propose to define rte_wmb() and rte_rmb() as asm sync, like
> > rte_mb(), since using lwsync is incorrect for them.
> > >
> > > Regards,
> > > Dekel
> > >
> > > From: Chao Zhu <chaozhu@linux.vnet.ibm.com>
> > > > Dekel£¬
> > > >
> > > > To control the memory order for device memory, I think you should
> > > > use
> > > > rte_io_mb() instead of rte_mb(). This will generate correct result.
> > > > rte_wmb() is used for system memory.
> > > >
> > > > From: Dekel Peled <dekelp@mellanox.com>
> > > > >
> > > > > From previous patch description: "to improve performance on PPC64,
> > > > > use light weight sync instruction instead of sync instruction."
> > > > >
> > > > > Excerpt from IBM doc [1], section "Memory barrier instructions":
> > > > > "The second form of the sync instruction is light-weight sync, or lwsync.
> > > > > This form is used to control ordering for storage accesses to
> > > > > system memory only. It does not create a memory barrier for
> > > > > accesses to device
> > > > memory."
> > > > >
> > > > > This patch removes the use of lwsync, so calls to rte_wmb() and
> > > > > rte_rmb() will provide correct memory barrier to ensure order of
> > > > > accesses to system memory and device memory.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
[not found] ` <OF129065AB.1B264FB9-ON882583C3.00792656-882583C3.007C9172@notes.na.collabserv.com>
@ 2019-03-21 8:49 ` Shahaf Shuler
0 siblings, 0 replies; 8+ messages in thread
From: Shahaf Shuler @ 2019-03-21 8:49 UTC (permalink / raw)
To: pradeep, Thomas Monjalon
Cc: Chao Zhu, Dekel Peled, dev, Ori Kam, stable, Yongseok Koh,
David Christensen, David Wilder
Pradeep Satyanarayana <pradeep@us.ibm.com> wrote on Thu 3/21/2019 12:41 AM:
>Thomas Monjalon <thomas@monjalon.net> wrote on 03/19/2019 01:45:01 PM:
>
>> From: Thomas Monjalon <thomas@monjalon.net>
>> To: Shahaf Shuler <shahafs@mellanox.com>
>> Cc: Dekel Peled <dekelp@mellanox.com>, Chao Zhu
>> <chaozhu@linux.vnet.ibm.com>, Yongseok Koh <yskoh@mellanox.com>,
>> "dev@dpdk.org" <dev@dpdk.org>, Ori Kam <orika@mellanox.com>,
>> "stable@dpdk.org" <stable@dpdk.org>, pradeep@us.ibm.com
>> Date: 03/19/2019 01:45 PM
>> Subject: Re: [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
>>
[...]
>> >
>> > So far, when not running on power, we used the rte_wmb for that.
>> On x86 and ARM systems it provided the needed guarantees.
>> > It is also mentioned in the barrier doxygen on ARM arch:
>> > "
>> > Write memory barrier.
>> >
>> > Guarantees that the STORE operations generated before the barrier
>> > occur before the STORE operations generated after.
>> > "
>> >
>> > It doesn't restrict to store to system memory only.
>> > w/ power is on somewhat different and in fact rte_mb is required.
>> It obviously miss the point of those barrier if we will need to use
>> a different barrier based on the system arch.
>> >
>> > We need to align the definition of the different barriers in DPDK:
>> > 1. need a clear documentation of each. this should be global and
>> not part of the specific implementation on each arch.
>
>A single approach may not work for all architectures. Power is different
>from others, so we need to be able to accommodate that. More comments below.
it don't get this claim.
It is ok to have some differences between the different arch, but here you implement a well-defined barrier - rte_wmb.
if you see a need we can discuss to define a **new** barrier which sync STORE only to system memory, and will be able to utilize the lwsync command.
>
>>
>> The global definition is in lib/librte_eal/common/include/generic/rte_atomic.h
>>
>> There are some copy/paste in Arm32 and PPC that I will remove.
>>
>> > 2. either modify ppc rte_wmb to match ARM and x86 ones or to
>> define a new type of barrier which will sync between both I/O and
>> stores to systems memory.
>>
>> The basic memory barrier of DPDK does not mention
>> a difference between I/O and system memory.
>
>In the case of Power, sync will cater to both I/O and system memory. However, that
>is too big a hammer in all cases.
rte_wmb requires such sync. you propose to have the wrong barrier in favor of performance.
to mitigate this you can take my suggestion above and define a new, more lightweight one.
>
>> It is not explicit (yet) but I assume it is protecting both.
>> So, in my opinion, we need to make it explicit in the doc,
>> and fix the PPC implementation to comply with this definition.
>>
>> Anyway, I don't see any significant effort from IBM to move from
>> the alpha support stage to a real Open Source support.
>> PS: sending a mail every two months, to promise improvements, is not enough!
>
[...]
>
>We should retain lwsync, should not be removed as discussed in here:
>
>http://mails.dpdk.org/archives/dev/2019-March/126746.html
i don't agree.
it is very clear the rte_wmb implementation in power is broken and we need to fix this right away before other customers will hit the same issue.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER
2019-03-18 12:58 [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER Dekel Peled
2019-03-19 3:24 ` Chao Zhu
@ 2019-03-28 22:50 ` Thomas Monjalon
1 sibling, 0 replies; 8+ messages in thread
From: Thomas Monjalon @ 2019-03-28 22:50 UTC (permalink / raw)
To: Dekel Peled
Cc: stable, chaozhu, yskoh, shahafs, dev, orika, pradeep, David Christensen
18/03/2019 13:58, Dekel Peled:
> From previous patch description: "to improve performance on PPC64,
> use light weight sync instruction instead of sync instruction."
>
> Excerpt from IBM doc [1], section "Memory barrier instructions":
> "The second form of the sync instruction is light-weight sync,
> or lwsync.
> This form is used to control ordering for storage accesses to system
> memory only. It does not create a memory barrier for accesses to
> device memory."
>
> This patch removes the use of lwsync, so calls to rte_wmb() and
> rte_rmb() will provide correct memory barrier to ensure order of
> accesses to system memory and device memory.
>
> [1] https://www.ibm.com/developerworks/systems/articles/powerpc.html
>
> Fixes: d23a6bd04d72 ("eal/ppc: fix memory barrier for IBM POWER")
> Cc: stable@dpdk.org
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Applied, thanks
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-03-28 22:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-18 12:58 [dpdk-stable] [PATCH] eal/ppc: remove fix of memory barrier for IBM POWER Dekel Peled
2019-03-19 3:24 ` Chao Zhu
2019-03-19 10:05 ` Dekel Peled
2019-03-19 11:14 ` Thomas Monjalon
2019-03-19 19:42 ` Shahaf Shuler
2019-03-19 20:45 ` Thomas Monjalon
[not found] ` <OF129065AB.1B264FB9-ON882583C3.00792656-882583C3.007C9172@notes.na.collabserv.com>
2019-03-21 8:49 ` Shahaf Shuler
2019-03-28 22:50 ` Thomas Monjalon
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).