DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Eads, Gage" <gage.eads@intel.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"arybchenko@solarflare.com" <arybchenko@solarflare.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Ananyev, Konstantin" <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: Fri, 1 Feb 2019 17:11:03 +0000	[thread overview]
Message-ID: <9184057F7FC11744A2107296B6B8EB1E541CE21A@FMSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <AM6PR08MB3672F4C0FCCFC7B5DFF7CD6E98910@AM6PR08MB3672.eurprd08.prod.outlook.com>



> -----Original Message-----
> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Wednesday, January 30, 2019 11:48 PM
> To: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org
> Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Gavin Hu (Arm Technology China)
> <Gavin.Hu@arm.com>; nd <nd@arm.com>; chaozhu@linux.vnet.ibm.com;
> jerinj@marvell.com; hemant.agrawal@nxp.com; nd <nd@arm.com>
> Subject: RE: [PATCH 1/1] eal: add 128-bit cmpset (x86-64 only)
> 
> >
> > 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?
> 

Good point, though for v2 I'm planning to change this to true cmpset semantics (no update to exp on failure). See Ola's reply for the justification.

> > +		     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.
> 

Will add in v2.

> > +
> > +/**
> > + * 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.
> 

Will change in v2. I was trying to avoid issues with GCC versions that don't have C++11 support, but DPDK's recommended minimum version (4.9) is later than the version that added __atomic builtins (4.7).

> > +
> > +/* 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.
> 

Sure.

Thanks,
Gage

<snip>

  reply	other threads:[~2019-02-01 17:11 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
2019-02-01 17:11     ` Eads, Gage [this message]
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=9184057F7FC11744A2107296B6B8EB1E541CE21A@FMSMSX108.amr.corp.intel.com \
    --to=gage.eads@intel.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=chaozhu@linux.vnet.ibm.com \
    --cc=dev@dpdk.org \
    --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).