DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Joyce Kong <joyce.kong@arm.com>, <honnappa.nagarahalli@arm.com>,
	<ruifeng.wang@arm.com>
Cc: <dev@dpdk.org>, <nd@arm.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [PATCH] kni: remove non-C11 path from FIFO sync
Date: Mon, 15 Nov 2021 23:25:36 +0000	[thread overview]
Message-ID: <a075e6c1-d8bb-4234-6003-d2fb7f234372@intel.com> (raw)
In-Reply-To: <20210819060442.19014-1-joyce.kong@arm.com>

On 8/19/2021 7:04 AM, Joyce Kong wrote:
> Non-C11 path was meant to not break build with GCC version < 4.7(when
> C11 atomics were introduced), while now minimum GCC version supported
> by DPDK has been 4.9, C11 atomics support in compiler is no longer a
> problem. So non-C11 path can be removed.

As far as I remember the non-C11 path implemented because of performance
difference, wasn't it, please check commit:
https://git.dpdk.org/dpdk/commit/?id=39368ebfc6067d0c82d76bdf4298ff9b8d257f21

Can you please point the reference where discussed to have non-C11 for because
of old compiler support?


Also how x86 is affected?
Previously it was just assignment because it was using non-C11 model and
'rte_smp_rmb' & 'rte_smp_wmb' are only compiler barrier.
Is the '__atomic_load_n()' noop for the x86? Since we are removing 'volatile'
from variables, I suspect it is not.


And finally, is there a downside to keep both models?

> 
> Signed-off-by: Joyce Kong <joyce.kong@arm.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> ---
>   lib/kni/rte_kni_common.h |  9 ++------
>   lib/kni/rte_kni_fifo.h   | 48 +++++++---------------------------------
>   2 files changed, 10 insertions(+), 47 deletions(-)
> 
> diff --git a/lib/kni/rte_kni_common.h b/lib/kni/rte_kni_common.h
> index b547ea5501..20d94eaa9b 100644
> --- a/lib/kni/rte_kni_common.h
> +++ b/lib/kni/rte_kni_common.h
> @@ -58,13 +58,8 @@ struct rte_kni_request {
>    * Writing should never overwrite the read position
>    */
>   struct rte_kni_fifo {
> -#ifdef RTE_USE_C11_MEM_MODEL
> -	unsigned write;              /**< Next position to be written*/
> -	unsigned read;               /**< Next position to be read */
> -#else
> -	volatile unsigned write;     /**< Next position to be written*/
> -	volatile unsigned read;      /**< Next position to be read */
> -#endif
> +	unsigned write;     /**< Next position to be written*/
> +	unsigned read;      /**< Next position to be read */
>   	unsigned len;                /**< Circular buffer length */
>   	unsigned elem_size;          /**< Pointer size - for 32/64 bit OS */
>   	void *volatile buffer[];     /**< The buffer contains mbuf pointers */
> diff --git a/lib/kni/rte_kni_fifo.h b/lib/kni/rte_kni_fifo.h
> index d2ec82fe87..057f6b3ded 100644
> --- a/lib/kni/rte_kni_fifo.h
> +++ b/lib/kni/rte_kni_fifo.h
> @@ -2,38 +2,6 @@
>    * Copyright(c) 2010-2014 Intel Corporation
>    */
>   
> -
> -
> -/**
> - * @internal when c11 memory model enabled use c11 atomic memory barrier.
> - * when under non c11 memory model use rte_smp_* memory barrier.
> - *
> - * @param src
> - *   Pointer to the source data.
> - * @param dst
> - *   Pointer to the destination data.
> - * @param value
> - *   Data value.
> - */
> -#ifdef RTE_USE_C11_MEM_MODEL
> -#define __KNI_LOAD_ACQUIRE(src) ({                         \
> -		__atomic_load_n((src), __ATOMIC_ACQUIRE);           \
> -	})
> -#define __KNI_STORE_RELEASE(dst, value) do {               \
> -		__atomic_store_n((dst), value, __ATOMIC_RELEASE);   \
> -	} while(0)
> -#else
> -#define __KNI_LOAD_ACQUIRE(src) ({                         \
> -		typeof (*(src)) val = *(src);                       \
> -		rte_smp_rmb();                                      \
> -		val;                                                \
> -	})
> -#define __KNI_STORE_RELEASE(dst, value) do {               \
> -		*(dst) = value;                                     \
> -		rte_smp_wmb();                                      \
> -	} while(0)
> -#endif
> -
>   /**
>    * Initializes the kni fifo structure
>    */
> @@ -59,7 +27,7 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void **data, unsigned num)
>   	unsigned i = 0;
>   	unsigned fifo_write = fifo->write;
>   	unsigned new_write = fifo_write;
> -	unsigned fifo_read = __KNI_LOAD_ACQUIRE(&fifo->read);
> +	unsigned fifo_read = __atomic_load_n(&fifo->read, __ATOMIC_ACQUIRE);
>   
>   	for (i = 0; i < num; i++) {
>   		new_write = (new_write + 1) & (fifo->len - 1);
> @@ -69,7 +37,7 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void **data, unsigned num)
>   		fifo->buffer[fifo_write] = data[i];
>   		fifo_write = new_write;
>   	}
> -	__KNI_STORE_RELEASE(&fifo->write, fifo_write);
> +	__atomic_store_n(&fifo->write, fifo_write, __ATOMIC_RELEASE);
>   	return i;
>   }
>   
> @@ -81,7 +49,7 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void **data, unsigned num)
>   {
>   	unsigned i = 0;
>   	unsigned new_read = fifo->read;
> -	unsigned fifo_write = __KNI_LOAD_ACQUIRE(&fifo->write);
> +	unsigned fifo_write = __atomic_load_n(&fifo->write, __ATOMIC_ACQUIRE);
>   
>   	for (i = 0; i < num; i++) {
>   		if (new_read == fifo_write)
> @@ -90,7 +58,7 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void **data, unsigned num)
>   		data[i] = fifo->buffer[new_read];
>   		new_read = (new_read + 1) & (fifo->len - 1);
>   	}
> -	__KNI_STORE_RELEASE(&fifo->read, new_read);
> +	__atomic_store_n(&fifo->read, new_read, __ATOMIC_RELEASE);
>   	return i;
>   }
>   
> @@ -100,8 +68,8 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void **data, unsigned num)
>   static inline uint32_t
>   kni_fifo_count(struct rte_kni_fifo *fifo)
>   {
> -	unsigned fifo_write = __KNI_LOAD_ACQUIRE(&fifo->write);
> -	unsigned fifo_read = __KNI_LOAD_ACQUIRE(&fifo->read);
> +	unsigned fifo_write = __atomic_load_n(&fifo->write, __ATOMIC_ACQUIRE);
> +	unsigned fifo_read = __atomic_load_n(&fifo->read, __ATOMIC_ACQUIRE);
>   	return (fifo->len + fifo_write - fifo_read) & (fifo->len - 1);
>   }
>   
> @@ -111,7 +79,7 @@ kni_fifo_count(struct rte_kni_fifo *fifo)
>   static inline uint32_t
>   kni_fifo_free_count(struct rte_kni_fifo *fifo)
>   {
> -	uint32_t fifo_write = __KNI_LOAD_ACQUIRE(&fifo->write);
> -	uint32_t fifo_read = __KNI_LOAD_ACQUIRE(&fifo->read);
> +	uint32_t fifo_write = __atomic_load_n(&fifo->write, __ATOMIC_ACQUIRE);
> +	uint32_t fifo_read = __atomic_load_n(&fifo->read, __ATOMIC_ACQUIRE);
>   	return (fifo_read - fifo_write - 1) & (fifo->len - 1);
>   }
> 


      parent reply	other threads:[~2021-11-15 23:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19  6:04 Joyce Kong
2021-10-21  6:19 ` Joyce Kong
2021-11-15 23:25 ` Ferruh Yigit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a075e6c1-d8bb-4234-6003-d2fb7f234372@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=jerinj@marvell.com \
    --cc=joyce.kong@arm.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=nd@arm.com \
    --cc=ruifeng.wang@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).