[dpdk-dev,1/2] ring: fix declaration after code

Message ID VI1PR08MB31672DC75C7056EE577F14FA8F6E0@VI1PR08MB3167.eurprd08.prod.outlook.com (mailing list archive)
State Superseded, archived
Headers

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation fail apply issues

Commit Message

Gavin Hu May 28, 2018, 8:15 a.m. UTC
  Hi Andy,

See my inline comments.

-Gavin

-----Original Message-----
From: dev <dev-bounces@dpdk.org> On Behalf Of Andy Green

Sent: Monday, May 28, 2018 10:29 AM
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH 1/2] ring: fix declaration after code

On gcc 5.4.0 / native aarch64 from Ubuntu 16.04:

/home/agreen/lagopus/src/dpdk/build/include/
rte_ring_c11_mem.h: In function
'__rte_ring_move_prod_head':
/home/agreen/lagopus/src/dpdk/build/include/
rte_ring_c11_mem.h:69:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   const uint32_t cons_tail = r->cons.tail;
   ^
/home/agreen/lagopus/src/dpdk/build/include/
rte_ring_c11_mem.h: In function
'__rte_ring_move_cons_head':
/home/agreen/lagopus/src/dpdk/build/include/
rte_ring_c11_mem.h:136:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   const uint32_t prod_tail = r->prod.tail;
   ^

Signed-off-by: Andy Green <andy@warmcat.com>

Fixes: 39368ebfc6 ("ring: introduce C11 memory model barrier option")
---
 lib/librte_ring/rte_ring_c11_mem.h |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

  * (the result is always modulo 32 bits even if we have @@ -129,11 +131,13 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,

 /* move cons.head atomically */
 do {
+const uint32_t prod_tail = r->prod.tail;
+
 /* Restore n as it may change every loop */
 n = max;
 *old_head = __atomic_load_n(&r->cons.head,
 __ATOMIC_ACQUIRE);
-const uint32_t prod_tail = r->prod.tail;
+
 /* The subtraction is done between two unsigned 32bits value
  * (the result is always modulo 32 bits even if we have
  * cons_head > prod_tail). So 'entries' is always between 0

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
  

Comments

Andy Green May 28, 2018, 8:46 a.m. UTC | #1
On 05/28/2018 04:15 PM, Gavin Hu wrote:

>   do {
> +const uint32_t cons_tail = r->cons.tail;
> +
>   /* Reset n to the initial burst count */
>   n = max;
> 
>   *old_head = __atomic_load_n(&r->prod.head,
>   __ATOMIC_ACQUIRE);
> -const uint32_t cons_tail = r->cons.tail;
> +
> [Gavin Hu] The ACQUIRE and RELEASE pair protects anything that between the two must be visible to other threads when they perform an acquire operation on the same memory address. Your changes broke this semantics.  I advise to move the declaration before and keep the assignment in the old place.

I see, thanks for the tip.

How about just get rid of this temp altogether if access to it is locked 
during this sequence anyway?  It's not like we had to sample it after 
the lock then, or it's bringing anything else to the party.

So instead of cons_tail / prod_tail at all, replace directly with 
r->cons.tail / r->prod.tail at the single usage for each.

-Andy
  
Gavin Hu May 28, 2018, 8:54 a.m. UTC | #2
-----Original Message-----
From: Andy Green <andy@warmcat.com>

Sent: Monday, May 28, 2018 4:47 PM
To: Gavin Hu <Gavin.Hu@arm.com>; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/2] ring: fix declaration after code



On 05/28/2018 04:15 PM, Gavin Hu wrote:

>   do {

> +const uint32_t cons_tail = r->cons.tail;

> +

>   /* Reset n to the initial burst count */

>   n = max;

>

>   *old_head = __atomic_load_n(&r->prod.head,

>   __ATOMIC_ACQUIRE);

> -const uint32_t cons_tail = r->cons.tail;

> +

> [Gavin Hu] The ACQUIRE and RELEASE pair protects anything that between the two must be visible to other threads when they perform an acquire operation on the same memory address. Your changes broke this semantics.  I advise to move the declaration before and keep the assignment in the old place.


I see, thanks for the tip.

How about just get rid of this temp altogether if access to it is locked during this sequence anyway?  It's not like we had to sample it after the lock then, or it's bringing anything else to the party.

So instead of cons_tail / prod_tail at all, replace directly with
r->cons.tail / r->prod.tail at the single usage for each.
[Gavin Hu] I think it is ok.

-Andy

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
  

Patch

diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index cb3f82b1a..3cc339558 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -61,12 +61,14 @@  __rte_ring_move_prod_head(struct rte_ring *r, unsigned int is_sp,
 int success;

 do {
+const uint32_t cons_tail = r->cons.tail;
+
 /* Reset n to the initial burst count */
 n = max;

 *old_head = __atomic_load_n(&r->prod.head,
 __ATOMIC_ACQUIRE);
-const uint32_t cons_tail = r->cons.tail;
+
[Gavin Hu] The ACQUIRE and RELEASE pair protects anything that between the two must be visible to other threads when they perform an acquire operation on the same memory address. Your changes broke this semantics.  I advise to move the declaration before and keep the assignment in the old place.
 /*
  *  The subtraction is done between two unsigned 32bits value