From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: Gage Eads <gage.eads@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"konstantin.ananyev@intel.com" <konstantin.ananyev@intel.com>,
"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
nd <nd@arm.com>,
"chaozhu@linux.vnet.ibm.com" <chaozhu@linux.vnet.ibm.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH 1/1] eal: add 128-bit cmpset (x86-64 only)
Date: Thu, 31 Jan 2019 05:48:14 +0000 [thread overview]
Message-ID: <AM6PR08MB3672F4C0FCCFC7B5DFF7CD6E98910@AM6PR08MB3672.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20190128172945.27251-2-gage.eads@intel.com>
>
> This operation can be used for non-blocking algorithms, such as a non-
> blocking stack or ring.
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> .../common/include/arch/x86/rte_atomic_64.h | 31 +++++++++++
> lib/librte_eal/common/include/generic/rte_atomic.h | 65
> ++++++++++++++++++++++
> 2 files changed, 96 insertions(+)
>
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> index fd2ec9c53..b7b90b83e 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
> @@ -34,6 +34,7 @@
> /*
> * Inspired from FreeBSD src/sys/amd64/include/atomic.h
> * Copyright (c) 1998 Doug Rabson
> + * Copyright (c) 2019 Intel Corporation
> * All rights reserved.
> */
>
> @@ -46,6 +47,7 @@
>
> #include <stdint.h>
> #include <rte_common.h>
> +#include <rte_compat.h>
> #include <rte_atomic.h>
>
> /*------------------------- 64 bit atomic operations -------------------------*/ @@ -
> 208,4 +210,33 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v) }
> #endif
>
> +static inline int __rte_experimental
> +rte_atomic128_cmpset(volatile rte_int128_t *dst,
Does it make sense to call is rte_atomic128_compare_exchange (or ..._cmp_xchg) to indicate it is a compare-exchange operation?
> + rte_int128_t *exp, rte_int128_t *src,
> + unsigned int weak,
> + enum rte_atomic_memmodel_t success,
> + enum rte_atomic_memmodel_t failure) {
> + RTE_SET_USED(weak);
> + RTE_SET_USED(success);
> + RTE_SET_USED(failure);
> + uint8_t res;
> +
> + asm volatile (
> + MPLOCKED
> + "cmpxchg16b %[dst];"
> + " sete %[res]"
> + : [dst] "=m" (dst->val[0]),
> + "=A" (exp->val[0]),
> + [res] "=r" (res)
> + : "c" (src->val[1]),
> + "b" (src->val[0]),
> + "m" (dst->val[0]),
> + "d" (exp->val[1]),
> + "a" (exp->val[0])
> + : "memory");
> +
> + return res;
> +}
> +
> #endif /* _RTE_ATOMIC_X86_64_H_ */
> diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h
> b/lib/librte_eal/common/include/generic/rte_atomic.h
> index b99ba4688..8d612d566 100644
> --- a/lib/librte_eal/common/include/generic/rte_atomic.h
> +++ b/lib/librte_eal/common/include/generic/rte_atomic.h
> @@ -14,6 +14,7 @@
>
> #include <stdint.h>
> #include <rte_common.h>
> +#include <rte_compat.h>
>
> #ifdef __DOXYGEN__
>
> @@ -1082,4 +1083,68 @@ static inline void
> rte_atomic64_clear(rte_atomic64_t *v) } #endif
>
> +/*------------------------ 128 bit atomic operations
> +-------------------------*/
> +
> +/**
> + * 128-bit integer structure.
> + */
> +typedef struct {
> + uint64_t val[2];
> +} __rte_aligned(16) rte_int128_t;
It looks like '__int128' is available from gcc 4.6. I think we should use '__int128'. We can have it as an internal structure for ease of programming.
> +
> +/**
> + * Memory consistency models used in atomic operations. These control
> +the
> + * behavior of the operation with respect to memory barriers and
> + * thread synchronization.
> + *
> + * These directly match those in the C++11 standard; for details on
> +their
> + * behavior, refer to the standard.
> + */
> +enum rte_atomic_memmodel_t {
> + RTE_ATOMIC_RELAXED,
> + RTE_ATOMIC_CONSUME,
> + RTE_ATOMIC_ACQUIRE,
> + RTE_ATOMIC_RELEASE,
> + RTE_ATOMIC_ACQ_REL,
> + RTE_ATOMIC_SEQ_CST,
> +};
IMO, we can use the GCC provided names. I do not see any advantage to defining our own.
> +
> +/* Only implemented on x86-64 currently. The ifdef prevents compilation
> +from
> + * failing for architectures without a definition of this function.
> + */
Minor comment. We can skip the above comments, the #if below is pretty obvious.
> +#if defined(RTE_ARCH_X86_64)
> +/**
> + * An atomic compare and set function used by the mutex functions.
> + * (atomic) equivalent to:
> + * if (*dst == exp)
> + * *dst = src (all 128-bit words)
> + *
> + * @param dst
> + * The destination into which the value will be written.
> + * @param exp
> + * Pointer to the expected value. If the operation fails, this memory is
> + * updated with the actual value.
> + * @param src
> + * Pointer to the new value.
> + * @param weak
> + * A value of true allows the comparison to spuriously fail.
> Implementations
> + * may ignore this argument and only implement the strong variant.
> + * @param success
> + * If successful, the operation's memory behavior conforms to this (or a
> + * stronger) model.
> + * @param failure
> + * If unsuccessful, the operation's memory behavior conforms to this (or a
> + * stronger) model. This argument cannot be RTE_ATOMIC_RELEASE,
> + * RTE_ATOMIC_ACQ_REL, or a stronger model than success.
> + * @return
> + * Non-zero on success; 0 on failure.
> + */
> +static inline int __rte_experimental
> +rte_atomic128_cmpset(volatile rte_int128_t *dst,
> + rte_int128_t *exp, rte_int128_t *src,
> + unsigned int weak,
> + enum rte_atomic_memmodel_t success,
> + enum rte_atomic_memmodel_t failure); #endif
> +
> #endif /* _RTE_ATOMIC_H_ */
> --
> 2.13.6
next prev parent reply other threads:[~2019-01-31 5:48 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 17:29 [dpdk-dev] [PATCH 0/1] Add 128-bit compare and set Gage Eads
2019-01-28 17:29 ` [dpdk-dev] [PATCH 1/1] eal: add 128-bit cmpset (x86-64 only) Gage Eads
2019-01-28 23:01 ` Ola Liljedahl
2019-02-01 17:06 ` Eads, Gage
2019-02-01 19:01 ` Ola Liljedahl
2019-02-01 19:28 ` Eads, Gage
2019-02-01 19:43 ` Ola Liljedahl
2019-02-01 21:05 ` Eads, Gage
2019-02-01 23:11 ` Ola Liljedahl
2019-02-04 18:33 ` Honnappa Nagarahalli
2019-01-31 5:48 ` Honnappa Nagarahalli [this message]
2019-02-01 17:11 ` Eads, Gage
2019-02-22 15:46 ` [dpdk-dev] [PATCH v2 0/1] Add 128-bit compare and set Gage Eads
2019-02-22 15:46 ` [dpdk-dev] [PATCH v2 1/1] eal: add 128-bit cmpxchg (x86-64 only) Gage Eads
2019-03-04 20:19 ` Honnappa Nagarahalli
2019-03-04 20:47 ` Eads, Gage
2019-03-04 20:51 ` [dpdk-dev] [PATCH v3 0/1] Add 128-bit compare and set Gage Eads
2019-03-04 20:51 ` [dpdk-dev] [PATCH v3 1/1] eal: add 128-bit compare exchange (x86-64 only) Gage Eads
2019-03-27 23:12 ` Thomas Monjalon
2019-03-27 23:12 ` Thomas Monjalon
2019-03-28 16:22 ` Eads, Gage
2019-03-28 16:22 ` Eads, Gage
2019-04-03 17:34 ` [dpdk-dev] [PATCH v4 0/1] Add 128-bit compare and set Gage Eads
2019-04-03 17:34 ` Gage Eads
2019-04-03 17:34 ` [dpdk-dev] [PATCH v4 1/1] eal: add 128-bit compare exchange (x86-64 only) Gage Eads
2019-04-03 17:34 ` Gage Eads
2019-04-03 19:04 ` Thomas Monjalon
2019-04-03 19:04 ` Thomas Monjalon
2019-04-03 19:21 ` Eads, Gage
2019-04-03 19:21 ` Eads, Gage
2019-04-03 19:27 ` Thomas Monjalon
2019-04-03 19:27 ` Thomas Monjalon
2019-04-03 19:35 ` [dpdk-dev] [PATCH v5] eal/x86: add 128-bit atomic compare exchange Thomas Monjalon
2019-04-03 19:35 ` Thomas Monjalon
2019-04-03 19:44 ` [dpdk-dev] [PATCH v6] " Gage Eads
2019-04-03 19:44 ` Gage Eads
2019-04-03 20:01 ` Thomas Monjalon
2019-04-03 20:01 ` Thomas Monjalon
2019-04-04 11:47 ` Ferruh Yigit
2019-04-04 11:47 ` Ferruh Yigit
2019-04-04 12:08 ` Thomas Monjalon
2019-04-04 12:08 ` Thomas Monjalon
2019-04-04 12:12 ` Thomas Monjalon
2019-04-04 12:12 ` Thomas Monjalon
2019-04-04 12:14 ` Eads, Gage
2019-04-04 12:14 ` Eads, Gage
2019-04-04 12:18 ` Thomas Monjalon
2019-04-04 12:18 ` Thomas Monjalon
2019-04-04 12:22 ` Eads, Gage
2019-04-04 12:22 ` Eads, Gage
2019-04-04 12:24 ` Eads, Gage
2019-04-04 12:24 ` Eads, Gage
2019-04-04 12:52 ` Ferruh Yigit
2019-04-04 12:52 ` Ferruh Yigit
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=AM6PR08MB3672F4C0FCCFC7B5DFF7CD6E98910@AM6PR08MB3672.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Gavin.Hu@arm.com \
--cc=arybchenko@solarflare.com \
--cc=bruce.richardson@intel.com \
--cc=chaozhu@linux.vnet.ibm.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=nd@arm.com \
--cc=olivier.matz@6wind.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).