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);
> }
>
prev 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).