From: "Phil Yang (Arm Technology China)" <Phil.Yang@arm.com>
To: "jerinj@marvell.com" <jerinj@marvell.com>,
"gage.eads@intel.com" <gage.eads@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
nd <nd@arm.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange
Date: Fri, 19 Jul 2019 13:56:27 +0000 [thread overview]
Message-ID: <VE1PR08MB46402CC0398C6BF5E0579211E9CB0@VE1PR08MB4640.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <BYAPR18MB2424326A53FD2A58D9786AD8C8CB0@BYAPR18MB2424.namprd18.prod.outlook.com>
> -----Original Message-----
> From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Sent: Friday, July 19, 2019 8:35 PM
> To: Phil Yang (Arm Technology China) <Phil.Yang@arm.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; hemant.agrawal@nxp.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology
> China) <Gavin.Hu@arm.com>; nd <nd@arm.com>; gage.eads@intel.com; nd
> <nd@arm.com>
> Subject: RE: [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare
> exchange
>
> > > > +#define RTE_HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) !=
> > > > +__ATOMIC_RELEASE) #define RTE_HAS_RLS(mo) ((mo) ==
> > > > __ATOMIC_RELEASE || \
> > > > + (mo) == __ATOMIC_ACQ_REL || \
> > > > + (mo) == __ATOMIC_SEQ_CST)
> > > > +
> > > > +#define RTE_MO_LOAD(mo) (RTE_HAS_ACQ((mo)) \
> > > > + ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED) #define
> > > > RTE_MO_STORE(mo)
> > > > +(RTE_HAS_RLS((mo)) \
> > > > + ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
> > > > +
> > >
> > > The one starts with RTE_ are public symbols, If it is generic enough,
> > > Move to common layer so that every architecturse can use.
> > > If you think, otherwise make it internal
> >
> > Let's keep it internal. I will remove the 'RTE_' tag.
>
> Probably change to __HAS_ACQ to avoid collision(just in case)
OK.
>
> > >
> > >
> > >
> > > > +#ifdef __ARM_FEATURE_ATOMICS
> > >
> > > This define is added in gcc 9.1 and I believe for clang it is not supported
> yet.
> > > So old gcc and clang this will be undefined.
> > > I think, With meson + native build, we can find the presence of
> > > ATOMIC support by running a.out. Not sure about make and cross build
> case.
> > > I don't want block this feature because of this, IMO, We can add this
> > > code with existing __ARM_FEATURE_ATOMICS scheme and later find a
> > > method to enhance it. But please check how to fix it.
> >
> > OK.
>
> After thinking on this a bit, I think, in order to support old gcc(< gcc 9.1) and
> clang,
> We can introduce a config option, where, by default it is disabled and enable
> In specific config(where we know, lse is supported) and meson config.
>
> i.e
> #if defined(__ARM_FEATURE_ATOMICS) ||
> defined(RTE_ARM_FEATURE_ATOMICS)
Cool
>
>
> >
> > >
> > > > +#define __ATOMIC128_CAS_OP(cas_op_name, op_string)
> \
> > > > +static inline rte_int128_t \
> > > > +cas_op_name(rte_int128_t *dst, rte_int128_t old, \
> > > > + rte_int128_t updated) \
> > > > +{ \
> > > > + /* caspX instructions register pair must start from even-numbered
> > > > + * register at operand 1.
> > > > + * So, specify registers for local variables here.
> > > > + */ \
> > > > + register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
> > >
> > > Since direct x0 register used in the code and
> > > cas_op_name() and rte_atomic128_cmp_exchange() is inline function,
> > > Based on parent function load, we may corrupt x0 register aka
> >
> > Since x0/x1 and x2/x3 are used a lot and often contain live values.
> > Maybe to change them to some relatively less frequently used registers
> like
> > x14/x15 and x16/x17 might help for this case?
> > According to the PCS (Procedure Call Standard), x14-x17 are also temporary
> > registers.
>
> X14-x17 are temporary registers but since
> cas_op_name() and rte_atomic128_cmp_exchange() are inline functions,
> Based on the parent function register usage, it _may_ corrupt.
Just checked how Linux Kernel does similar things:
https://github.com/torvalds/linux/blob/master/arch/arm64/include/asm/atomic_lse.h#L19
Same methods.
I will finish the benchmarking for the no_inline approach. If it has no significant performance loss, I think we can make it as no_inline.
>
>
> >
> > > Break arm64 ABI. Not sure clobber list will help here or not?
> >
> > In my understanding, for the register variable, if it contains a live value in
> the
> > specified register, the compiler will move the live value into a free register.
> > Since x0~x3 are present in the input/output operands and x0/x1's value
> needs to
> > be restored to the variable 'old' as a return value.
> > So I didn't add them into the clobber list.
>
> OK
>
> >
> > > Making it as no_inline will help but not sure about the performance
> impact.
> > > May be you can check with compiler team.
> > >
> > > We burned our hands with this scheme, see
> > > 5b40ec6b966260e0ff66a8a2c689664f75d6a0e6 ("mempool/octeontx2: fix
> > > possible arm64 ABI break")
> > >
> > > Probably we can choose a scheme for rc2 and adjust as when we have
> > > complete clarity.
> > >
> > > >
> > > > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_ARM64)
> > >
> > > There is nothing specific to x86 and arm64 here, Can we remove this
> #ifdef ?
> >
> > Without this constraint, it will break 32-bit x86 builds.
> > http://mails.dpdk.org/archives/test-report/2019-June/086586.html
>
> OK . #ifdef RTE_ARCH_64 would help then.
OK.
>
> >
> > >
> > > > +/**
> > > > + * 128-bit integer structure.
> > > > + */
> > > > +RTE_STD_C11
> > > > +typedef struct {
> > > > + RTE_STD_C11
> > > > + union {
> > > > + uint64_t val[2];
> > > > + __extension__ __int128 int128;
>
> Instead of guarding RTE_ARCH_64 on this complete structure,
> How about it only under
> #ifdef RTE_ARCH_64
> __extension__ __int128 int128;
> #endif
> So that it rte_int128_t will be available for 32bit as well.
Agree, it should be work. But I am not sure.
Hi Gage,
How do you think about this?
>
>
> > > > + };
> > > > +} __rte_aligned(16) rte_int128_t;
> > > > +#endif
> > > > +
> > > > #ifdef __DOXYGEN__
next prev parent reply other threads:[~2019-07-19 13:56 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-23 2:41 [dpdk-dev] [PATCH v1 " Phil Yang
2019-06-23 2:41 ` [dpdk-dev] [PATCH v1 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-06-23 2:41 ` [dpdk-dev] [PATCH v1 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-06-23 3:15 ` [dpdk-dev] [PATCH v2 1/3] eal/arm64: add 128-bit atomic compare exchange Phil Yang
2019-06-23 3:15 ` [dpdk-dev] [PATCH v2 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-06-24 15:09 ` Eads, Gage
2019-06-24 15:29 ` Phil Yang (Arm Technology China)
2019-06-23 3:15 ` [dpdk-dev] [PATCH v2 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-06-24 15:15 ` Eads, Gage
2019-06-24 15:22 ` Phil Yang (Arm Technology China)
2019-06-24 14:46 ` [dpdk-dev] [PATCH v2 1/3] eal/arm64: add 128-bit atomic compare exchange Eads, Gage
2019-06-24 15:35 ` Phil Yang (Arm Technology China)
2019-06-28 8:11 ` [dpdk-dev] [PATCH v3 " Phil Yang
2019-06-28 8:11 ` [dpdk-dev] [PATCH v3 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-06-29 0:17 ` Eads, Gage
2019-07-19 4:03 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-06-28 8:11 ` [dpdk-dev] [PATCH v3 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-06-29 0:18 ` Eads, Gage
2019-07-19 4:18 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-19 4:42 ` Eads, Gage
2019-07-19 5:02 ` Jerin Jacob Kollanukkaran
2019-07-19 5:15 ` Phil Yang (Arm Technology China)
2019-07-03 12:25 ` [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange Jerin Jacob Kollanukkaran
2019-07-03 13:07 ` Jerin Jacob Kollanukkaran
2019-07-05 4:20 ` Honnappa Nagarahalli
2019-07-05 4:37 ` Pavan Nikhilesh Bhagavatula
2019-07-09 9:27 ` Phil Yang (Arm Technology China)
2019-07-09 11:14 ` Jerin Jacob Kollanukkaran
2019-07-19 6:24 ` Jerin Jacob Kollanukkaran
2019-07-19 11:01 ` Phil Yang (Arm Technology China)
2019-07-19 12:35 ` Jerin Jacob Kollanukkaran
2019-07-19 13:56 ` Phil Yang (Arm Technology China) [this message]
2019-07-19 14:50 ` Eads, Gage
2019-07-22 8:44 ` [dpdk-dev] [PATCH v4 " Phil Yang
2019-07-22 8:44 ` [dpdk-dev] [PATCH v4 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-07-22 8:44 ` [dpdk-dev] [PATCH v4 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-07-22 10:22 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-22 11:51 ` Phil Yang (Arm Technology China)
2019-07-22 10:20 ` [dpdk-dev] [EXT] [PATCH v4 1/3] eal/arm64: add 128-bit atomic compare exchange Jerin Jacob Kollanukkaran
2019-07-22 11:50 ` Phil Yang (Arm Technology China)
2019-07-22 13:06 ` [dpdk-dev] [PATCH v5 " Phil Yang
2019-07-22 13:06 ` [dpdk-dev] [PATCH v5 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-07-22 13:06 ` [dpdk-dev] [PATCH v5 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-07-22 14:14 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-22 15:19 ` Phil Yang (Arm Technology China)
2019-07-22 14:34 ` [dpdk-dev] " Eads, Gage
2019-07-22 14:43 ` Phil Yang (Arm Technology China)
2019-07-22 14:19 ` [dpdk-dev] [EXT] [PATCH v5 1/3] eal/arm64: add 128-bit atomic compare exchange Jerin Jacob Kollanukkaran
2019-07-22 16:23 ` Phil Yang (Arm Technology China)
2019-07-22 16:22 ` [dpdk-dev] [PATCH v6 " Phil Yang
2019-07-22 16:22 ` [dpdk-dev] [PATCH v6 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-07-22 16:22 ` [dpdk-dev] [PATCH v6 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-07-22 16:59 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-22 16:57 ` [dpdk-dev] [EXT] [PATCH v6 1/3] eal/arm64: add 128-bit atomic compare exchange Jerin Jacob Kollanukkaran
2019-07-23 3:28 ` Phil Yang (Arm Technology China)
2019-07-23 7:09 ` Jerin Jacob Kollanukkaran
2019-07-23 7:53 ` Phil Yang (Arm Technology China)
2019-07-23 5:57 ` [dpdk-dev] [PATCH v7 " Phil Yang
2019-07-23 5:57 ` [dpdk-dev] [PATCH v7 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-07-23 5:57 ` [dpdk-dev] [PATCH v7 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-07-23 7:05 ` [dpdk-dev] [PATCH v8 1/3] eal/arm64: add 128-bit atomic compare exchange jerinj
2019-07-23 7:05 ` [dpdk-dev] [PATCH v8 2/3] test/atomic: add 128b compare and swap test jerinj
2019-07-23 7:05 ` [dpdk-dev] [PATCH v8 3/3] eal/stack: enable lock-free stack for aarch64 jerinj
2019-08-14 8:27 ` [dpdk-dev] [PATCH v9 1/3] eal/arm64: add 128-bit atomic compare exchange Phil Yang
2019-08-14 8:27 ` [dpdk-dev] [PATCH v9 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-10-14 15:45 ` David Marchand
2019-10-15 11:32 ` Phil Yang (Arm Technology China)
2019-08-14 8:27 ` [dpdk-dev] [PATCH v9 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-10-14 15:45 ` David Marchand
2019-10-15 11:32 ` Phil Yang (Arm Technology China)
2019-10-14 15:43 ` [dpdk-dev] [PATCH v9 1/3] eal/arm64: add 128-bit atomic compare exchange David Marchand
2019-10-15 11:32 ` Phil Yang (Arm Technology China)
2019-10-15 12:16 ` David Marchand
2019-10-16 9:04 ` Phil Yang (Arm Technology China)
2019-10-17 12:45 ` David Marchand
2019-10-15 11:38 ` [dpdk-dev] [PATCH v10 " Phil Yang
2019-10-15 11:38 ` [dpdk-dev] [PATCH v10 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-10-15 11:38 ` [dpdk-dev] [PATCH v10 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-10-18 11:21 ` [dpdk-dev] [PATCH v11 1/3] eal/arm64: add 128-bit atomic compare exchange Phil Yang
2019-10-18 11:21 ` [dpdk-dev] [PATCH v11 2/3] test/atomic: add 128b compare and swap test Phil Yang
2019-10-21 8:25 ` David Marchand
2019-10-18 11:21 ` [dpdk-dev] [PATCH v11 3/3] eal/stack: enable lock-free stack for aarch64 Phil Yang
2019-10-21 8:26 ` David Marchand
2019-10-18 14:16 ` [dpdk-dev] [PATCH v11 1/3] eal/arm64: add 128-bit atomic compare exchange David Marchand
2019-10-18 14:24 ` Jerin Jacob
2019-10-18 14:33 ` David Marchand
2019-10-18 14:36 ` Jerin Jacob
2019-10-21 8:24 ` David Marchand
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=VE1PR08MB46402CC0398C6BF5E0579211E9CB0@VE1PR08MB4640.eurprd08.prod.outlook.com \
--to=phil.yang@arm.com \
--cc=Gavin.Hu@arm.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=dev@dpdk.org \
--cc=gage.eads@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=nd@arm.com \
--cc=thomas@monjalon.net \
/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).