From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Phil Yang <phil.yang@arm.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "david.marchand@redhat.com" <david.marchand@redhat.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"Honnappa.Nagarahalli@arm.com" <Honnappa.Nagarahalli@arm.com>,
"gavin.hu@arm.com" <gavin.hu@arm.com>,
"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
"joyce.kong@arm.com" <joyce.kong@arm.com>,
"nd@arm.com" <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v3 11/12] service: optimize with c11 one-way barrier
Date: Fri, 3 Apr 2020 11:58:23 +0000 [thread overview]
Message-ID: <BYAPR11MB314311EA8B6DBD782F76F529D7C70@BYAPR11MB3143.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1584407863-774-12-git-send-email-phil.yang@arm.com>
> -----Original Message-----
> From: Phil Yang <phil.yang@arm.com>
> Sent: Tuesday, March 17, 2020 1:18 AM
> To: thomas@monjalon.net; Van Haaren, Harry <harry.van.haaren@intel.com>;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> stephen@networkplumber.org; maxime.coquelin@redhat.com; dev@dpdk.org
> Cc: david.marchand@redhat.com; jerinj@marvell.com; hemant.agrawal@nxp.com;
> Honnappa.Nagarahalli@arm.com; gavin.hu@arm.com; ruifeng.wang@arm.com;
> joyce.kong@arm.com; nd@arm.com
> Subject: [PATCH v3 11/12] service: optimize with c11 one-way barrier
>
> The num_mapped_cores and execute_lock are synchronized with rte_atomic_XX
> APIs which is a full barrier, DMB, on aarch64. This patch optimized it with
> c11 atomic one-way barrier.
>
> Signed-off-by: Phil Yang <phil.yang@arm.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Based on discussion on-list, it seems the consensus is to not use
GCC builtins, but instead use C11 APIs "proper"? If my conclusion is
correct, the v+1 of this patchset would require updates to that style API.
Inline comments for context below, -Harry
> ---
> lib/librte_eal/common/rte_service.c | 50 ++++++++++++++++++++++++++----------
> -
> 1 file changed, 35 insertions(+), 15 deletions(-)
>
> diff --git a/lib/librte_eal/common/rte_service.c
> b/lib/librte_eal/common/rte_service.c
> index 0843c3c..c033224 100644
> --- a/lib/librte_eal/common/rte_service.c
> +++ b/lib/librte_eal/common/rte_service.c
> @@ -42,7 +42,7 @@ struct rte_service_spec_impl {
> * running this service callback. When not set, a core may take the
> * lock and then run the service callback.
> */
> - rte_atomic32_t execute_lock;
> + uint32_t execute_lock;
>
> /* API set/get-able variables */
> int8_t app_runstate;
> @@ -54,7 +54,7 @@ struct rte_service_spec_impl {
> * It does not indicate the number of cores the service is running
> * on currently.
> */
> - rte_atomic32_t num_mapped_cores;
> + int32_t num_mapped_cores;
Any reason why "int32_t" or "uint32_t" is used over another?
execute_lock is a uint32_t above, num_mapped_cores is an int32_t?
> uint64_t calls;
> uint64_t cycles_spent;
> } __rte_cache_aligned;
> @@ -332,7 +332,8 @@ rte_service_runstate_get(uint32_t id)
> rte_smp_rmb();
>
> int check_disabled = !(s->internal_flags & SERVICE_F_START_CHECK);
> - int lcore_mapped = (rte_atomic32_read(&s->num_mapped_cores) > 0);
> + int lcore_mapped = (__atomic_load_n(&s->num_mapped_cores,
> + __ATOMIC_RELAXED) > 0);
>
> return (s->app_runstate == RUNSTATE_RUNNING) &&
> (s->comp_runstate == RUNSTATE_RUNNING) &&
> @@ -375,11 +376,20 @@ service_run(uint32_t i, struct core_state *cs, uint64_t
> service_mask,
> cs->service_active_on_lcore[i] = 1;
>
> if ((service_mt_safe(s) == 0) && (serialize_mt_unsafe == 1)) {
> - if (!rte_atomic32_cmpset((uint32_t *)&s->execute_lock, 0, 1))
> + uint32_t expected = 0;
> + /* ACQUIRE ordering here is to prevent the callback
> + * function from hoisting up before the execute_lock
> + * setting.
> + */
> + if (!__atomic_compare_exchange_n(&s->execute_lock, &expected, 1,
> + 0, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED))
> return -EBUSY;
Let's try improve the magic "1" and "0" constants, I believe the "1" here
is the desired "new value on success", and the 0 is "bool weak", where our 0/false constant implies a strongly ordered compare exchange?
"Weak is true for weak compare_exchange, which may fail spuriously, and false for the strong variation, which never fails spuriously.", from https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
const uint32_t on_success_value = 1;
const bool weak = 0;
__atomic_compare_exchange_n(&s->execute_lock, &expected, on_success_value, weak, __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
Although a bit more verbose, I feel this documents usage a lot better,
particularly for those who aren't as familiar with the C11 function
arguments order.
Admittedly with the API change to not use __builtins, perhaps this
comment is moot.
>
> service_runner_do_callback(s, cs, i);
> - rte_atomic32_clear(&s->execute_lock);
> + /* RELEASE ordering here is used to pair with ACQUIRE
> + * above to achieve lock semantic.
> + */
> + __atomic_store_n(&s->execute_lock, 0, __ATOMIC_RELEASE);
> } else
> service_runner_do_callback(s, cs, i);
>
> @@ -415,11 +425,11 @@ rte_service_run_iter_on_app_lcore(uint32_t id, uint32_t
> serialize_mt_unsafe)
> /* Increment num_mapped_cores to indicate that the service
> * is running on a core.
> */
> - rte_atomic32_inc(&s->num_mapped_cores);
> + __atomic_add_fetch(&s->num_mapped_cores, 1, __ATOMIC_ACQUIRE);
>
> int ret = service_run(id, cs, UINT64_MAX, s, serialize_mt_unsafe);
>
> - rte_atomic32_dec(&s->num_mapped_cores);
> + __atomic_sub_fetch(&s->num_mapped_cores, 1, __ATOMIC_RELEASE);
>
> return ret;
> }
> @@ -552,24 +562,32 @@ service_update(uint32_t sid, uint32_t lcore,
>
> uint64_t sid_mask = UINT64_C(1) << sid;
> if (set) {
> - uint64_t lcore_mapped = lcore_states[lcore].service_mask &
> - sid_mask;
> + /* When multiple threads try to update the same lcore
> + * service concurrently, e.g. set lcore map followed
> + * by clear lcore map, the unsynchronized service_mask
> + * values have issues on the num_mapped_cores value
> + * consistency. So we use ACQUIRE ordering to pair with
> + * the RELEASE ordering to synchronize the service_mask.
> + */
> + uint64_t lcore_mapped = __atomic_load_n(
> + &lcore_states[lcore].service_mask,
> + __ATOMIC_ACQUIRE) & sid_mask;
Thanks for the comment - it helps me understand things a bit better.
Some questions/theories to validate;
1) The service_mask ACQUIRE avoids other loads being hoisted above it, correct?
2) There are non-atomic stores to service_mask. Is it correct that the stores themselves aren't the issue, but relative visibility of service_mask stores vs num_mapped_cores? (Detail in (3) below)
> if (*set && !lcore_mapped) {
> lcore_states[lcore].service_mask |= sid_mask;
> - rte_atomic32_inc(&rte_services[sid].num_mapped_cores);
> + __atomic_add_fetch(&rte_services[sid].num_mapped_cores,
> + 1, __ATOMIC_RELEASE);
> }
> if (!*set && lcore_mapped) {
> lcore_states[lcore].service_mask &= ~(sid_mask);
> - rte_atomic32_dec(&rte_services[sid].num_mapped_cores);
> + __atomic_sub_fetch(&rte_services[sid].num_mapped_cores,
> + 1, __ATOMIC_RELEASE);
> }
3) Here we update the core-local service_mask, and then update the
num_mapped_cores with an ATOMIC_RELEASE. The RELEASE here ensures
that the previous store to service_mask is guaranteed to be visible
on all cores if this store is visible. Why do we care about this property?
The service_mask is core local anway.
4) Even with the load ACQ service_mask, and REL num_mapped_cores store, is there not still a race-condition possible where 2 lcores simultaneously load-ACQ the service_mask, and then both do atomic add/sub_fetch with REL?
5) Assuming 4 above race is true, it raises the real question - the service-cores control APIs are not designed to be multi-thread-safe. Orchestration of service/lcore mappings is not meant to be done by multiple threads at the same time. Documenting this loudly may help, I'm happy to send a patch to do so if we're agreed on the above?
> }
>
> if (enabled)
> *enabled = !!(lcore_states[lcore].service_mask & (sid_mask));
>
> - rte_smp_wmb();
> -
> return 0;
> }
>
> @@ -625,7 +643,8 @@ rte_service_lcore_reset_all(void)
> }
> }
> for (i = 0; i < RTE_SERVICE_NUM_MAX; i++)
> - rte_atomic32_set(&rte_services[i].num_mapped_cores, 0);
> + __atomic_store_n(&rte_services[i].num_mapped_cores, 0,
> + __ATOMIC_RELAXED);
>
> rte_smp_wmb();
>
> @@ -708,7 +727,8 @@ rte_service_lcore_stop(uint32_t lcore)
> int32_t enabled = service_mask & (UINT64_C(1) << i);
> int32_t service_running = rte_service_runstate_get(i);
> int32_t only_core = (1 ==
> - rte_atomic32_read(&rte_services[i].num_mapped_cores));
> + __atomic_load_n(&rte_services[i].num_mapped_cores,
> + __ATOMIC_RELAXED));
>
> /* if the core is mapped, and the service is running, and this
> * is the only core that is mapped, the service would cease to
> --
> 2.7.4
next prev parent reply other threads:[~2020-04-03 11:58 UTC|newest]
Thread overview: 219+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 17:49 [dpdk-dev] [PATCH 00/10] generic rte atomic APIs deprecate proposal Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 01/10] doc: add generic atomic deprecation section Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 02/10] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 03/10] vhost: optimize broadcast rarp sync with c11 atomic Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 04/10] ipsec: optimize with c11 atomic for sa outbound sqn update Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 05/10] service: remove rte prefix from static functions Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 06/10] service: remove redundant code Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 07/10] service: avoid race condition for MT unsafe service Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 08/10] service: identify service running on another core correctly Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 09/10] service: optimize with c11 one-way barrier Phil Yang
2020-03-10 17:49 ` [dpdk-dev] [PATCH 10/10] service: relax barriers with C11 atomic operations Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 00/10] generic rte atomic APIs deprecate proposal Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 01/10] doc: add generic atomic deprecation section Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 02/10] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 03/10] vhost: optimize broadcast rarp sync with c11 atomic Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 04/10] ipsec: optimize with c11 atomic for sa outbound sqn update Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 05/10] service: remove rte prefix from static functions Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 06/10] service: remove redundant code Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 07/10] service: avoid race condition for MT unsafe service Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 08/10] service: identify service running on another core correctly Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 09/10] service: optimize with c11 one-way barrier Phil Yang
2020-03-12 7:44 ` [dpdk-dev] [PATCH v2 10/10] service: relax barriers with C11 atomic operations Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 00/12] generic rte atomic APIs deprecate proposal Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 01/12] doc: add generic atomic deprecation section Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 02/12] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 03/12] eal/build: add libatomic dependency for 32-bit clang Phil Yang
2020-04-24 6:08 ` Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 04/12] build: remove redundant code Phil Yang
2020-04-24 6:14 ` Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 05/12] vhost: optimize broadcast rarp sync with c11 atomic Phil Yang
2020-04-23 16:54 ` [dpdk-dev] [PATCH v2] " Phil Yang
2020-04-27 8:57 ` Maxime Coquelin
2020-04-28 16:06 ` Maxime Coquelin
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 06/12] ipsec: optimize with c11 atomic for sa outbound sqn update Phil Yang
2020-03-23 18:48 ` Ananyev, Konstantin
2020-03-23 19:07 ` Honnappa Nagarahalli
2020-03-23 19:18 ` Ananyev, Konstantin
2020-03-23 20:20 ` Honnappa Nagarahalli
2020-03-24 13:10 ` Ananyev, Konstantin
2020-03-24 13:21 ` Ananyev, Konstantin
2020-03-24 10:37 ` Phil Yang
2020-03-24 11:03 ` Ananyev, Konstantin
2020-03-25 9:38 ` Phil Yang
2020-04-23 17:16 ` [dpdk-dev] [PATCH v2] " Phil Yang
2020-04-23 17:45 ` Jerin Jacob
2020-04-24 4:49 ` Phil Yang
2020-04-23 18:10 ` Ananyev, Konstantin
2020-04-24 4:35 ` Phil Yang
2020-04-24 4:33 ` [dpdk-dev] [PATCH v3] " Phil Yang
2020-04-24 11:17 ` Ananyev, Konstantin
2020-05-09 21:51 ` Akhil Goyal
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 07/12] service: remove rte prefix from static functions Phil Yang
2020-04-03 11:57 ` Van Haaren, Harry
2020-04-08 10:14 ` Phil Yang
2020-04-08 10:36 ` Van Haaren, Harry
2020-04-08 10:49 ` Phil Yang
2020-04-05 21:35 ` Honnappa Nagarahalli
2020-04-08 10:14 ` Phil Yang
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 0/6] use c11 atomics for service core lib Phil Yang
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 1/6] service: fix race condition for MT unsafe service Phil Yang
2020-04-29 16:51 ` Van Haaren, Harry
2020-04-29 22:48 ` Honnappa Nagarahalli
2020-05-01 14:21 ` Van Haaren, Harry
2020-05-01 14:56 ` Honnappa Nagarahalli
2020-05-01 17:51 ` Van Haaren, Harry
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 2/6] service: identify service running on another core correctly Phil Yang
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 3/6] service: remove rte prefix from static functions Phil Yang
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 4/6] service: remove redundant code Phil Yang
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 5/6] service: optimize with c11 atomics Phil Yang
2020-04-23 16:31 ` [dpdk-dev] [PATCH v2 6/6] service: relax barriers with C11 atomics Phil Yang
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 0/6] use c11 atomics for service core lib Honnappa Nagarahalli
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 1/6] service: fix race condition for MT unsafe service Honnappa Nagarahalli
2020-05-05 14:48 ` Van Haaren, Harry
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 2/6] service: identify service running on another core correctly Honnappa Nagarahalli
2020-05-05 14:48 ` Van Haaren, Harry
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 3/6] service: remove rte prefix from static functions Honnappa Nagarahalli
2020-05-05 14:48 ` Van Haaren, Harry
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 4/6] service: remove redundant code Honnappa Nagarahalli
2020-05-05 14:48 ` Van Haaren, Harry
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 5/6] service: optimize with c11 atomics Honnappa Nagarahalli
2020-05-05 14:48 ` Van Haaren, Harry
2020-05-02 0:02 ` [dpdk-dev] [PATCH v3 6/6] service: relax barriers with C11 atomics Honnappa Nagarahalli
2020-05-05 14:48 ` Van Haaren, Harry
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 0/6] use c11 atomics for service core lib Honnappa Nagarahalli
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 1/6] service: fix race condition for MT unsafe service Honnappa Nagarahalli
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 2/6] service: fix identification of service running on other lcore Honnappa Nagarahalli
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 3/6] service: remove rte prefix from static functions Honnappa Nagarahalli
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 4/6] service: remove redundant code Honnappa Nagarahalli
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 5/6] service: optimize with c11 atomics Honnappa Nagarahalli
2020-05-06 10:20 ` Phil Yang
2020-05-05 21:17 ` [dpdk-dev] [PATCH v4 6/6] service: relax barriers with C11 atomics Honnappa Nagarahalli
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 0/6] use c11 atomics for service core lib Phil Yang
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 1/6] service: fix race condition for MT unsafe service Phil Yang
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 2/6] service: fix identification of service running on other lcore Phil Yang
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 3/6] service: remove rte prefix from static functions Phil Yang
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 4/6] service: remove redundant code Phil Yang
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 5/6] service: optimize with c11 atomics Phil Yang
2020-05-06 10:24 ` [dpdk-dev] [PATCH v5 6/6] service: relax barriers with C11 atomics Phil Yang
2020-05-06 15:27 ` [dpdk-dev] [PATCH v6 0/6] use c11 atomics for service core lib Phil Yang
2020-05-06 15:27 ` [dpdk-dev] [PATCH v6 1/6] service: fix race condition for MT unsafe service Phil Yang
2020-05-06 15:28 ` [dpdk-dev] [PATCH v6 2/6] service: fix identification of service running on other lcore Phil Yang
2020-05-06 15:28 ` [dpdk-dev] [PATCH v6 3/6] service: remove rte prefix from static functions Phil Yang
2020-05-06 15:28 ` [dpdk-dev] [PATCH v6 4/6] service: remove redundant code Phil Yang
2020-05-06 15:28 ` [dpdk-dev] [PATCH v6 5/6] service: optimize with c11 atomics Phil Yang
2020-05-06 15:28 ` [dpdk-dev] [PATCH v6 6/6] service: relax barriers with C11 atomics Phil Yang
2020-05-11 11:21 ` [dpdk-dev] [PATCH v6 0/6] use c11 atomics for service core lib David Marchand
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 08/12] service: remove redundant code Phil Yang
2020-04-03 11:58 ` Van Haaren, Harry
2020-04-05 18:35 ` Honnappa Nagarahalli
2020-04-08 10:15 ` Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 09/12] service: avoid race condition for MT unsafe service Phil Yang
2020-04-03 11:58 ` Van Haaren, Harry
2020-04-04 18:03 ` Honnappa Nagarahalli
2020-04-08 18:05 ` Van Haaren, Harry
2020-04-09 1:31 ` Honnappa Nagarahalli
2020-04-09 16:46 ` Van Haaren, Harry
2020-04-18 6:21 ` Honnappa Nagarahalli
2020-04-21 17:43 ` Van Haaren, Harry
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 10/12] service: identify service running on another core correctly Phil Yang
2020-04-03 11:58 ` Van Haaren, Harry
2020-04-05 2:43 ` Honnappa Nagarahalli
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 11/12] service: optimize with c11 one-way barrier Phil Yang
2020-04-03 11:58 ` Van Haaren, Harry [this message]
2020-04-06 4:22 ` Honnappa Nagarahalli
2020-04-08 10:15 ` Phil Yang
2020-03-17 1:17 ` [dpdk-dev] [PATCH v3 12/12] service: relax barriers with C11 atomic operations Phil Yang
2020-04-03 11:58 ` Van Haaren, Harry
2020-04-06 17:06 ` Honnappa Nagarahalli
2020-04-08 19:42 ` Van Haaren, Harry
2020-03-18 14:01 ` [dpdk-dev] [PATCH v3 00/12] generic rte atomic APIs deprecate proposal Van Haaren, Harry
2020-03-18 15:13 ` Thomas Monjalon
2020-03-20 5:01 ` Honnappa Nagarahalli
2020-03-20 12:20 ` Jerin Jacob
2020-03-20 4:51 ` Honnappa Nagarahalli
2020-03-20 18:32 ` Honnappa Nagarahalli
2020-03-27 14:47 ` Van Haaren, Harry
2020-04-03 7:23 ` Mattias Rönnblom
2020-05-12 8:03 ` [dpdk-dev] [PATCH v4 0/4] " Phil Yang
2020-05-12 8:03 ` [dpdk-dev] [PATCH v4 1/4] doc: add generic atomic deprecation section Phil Yang
2020-05-12 8:03 ` [dpdk-dev] [PATCH v4 2/4] maintainers: claim maintainers of c11 atomics code Phil Yang
2020-05-24 23:11 ` Thomas Monjalon
2020-05-25 3:28 ` Phil Yang
2020-05-12 8:03 ` [dpdk-dev] [PATCH v4 3/4] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-05-12 8:03 ` [dpdk-dev] [PATCH v4 4/4] eal/atomic: add wrapper for c11 atomics Phil Yang
2020-05-12 11:18 ` Morten Brørup
2020-05-13 9:40 ` Phil Yang
2020-05-13 15:32 ` Honnappa Nagarahalli
2020-05-12 18:20 ` Stephen Hemminger
2020-05-12 19:23 ` Honnappa Nagarahalli
2020-05-13 8:57 ` Morten Brørup
2020-05-13 15:30 ` Honnappa Nagarahalli
2020-05-13 19:04 ` Mattias Rönnblom
2020-05-13 19:40 ` Honnappa Nagarahalli
2020-05-13 20:17 ` Mattias Rönnblom
2020-05-14 8:34 ` Morten Brørup
2020-05-14 20:16 ` Mattias Rönnblom
2020-05-14 21:00 ` Honnappa Nagarahalli
2020-05-13 11:53 ` Ananyev, Konstantin
2020-05-13 15:06 ` Honnappa Nagarahalli
2020-05-13 19:25 ` Mattias Rönnblom
2020-05-12 8:18 ` [dpdk-dev] [PATCH v4 0/4] generic rte atomic APIs deprecate proposal Phil Yang
2020-05-26 9:01 ` [dpdk-dev] [PATCH v5 " Phil Yang
2020-05-26 9:01 ` [dpdk-dev] [PATCH v5 1/4] doc: add generic atomic deprecation section Phil Yang
2020-05-26 9:01 ` [dpdk-dev] [PATCH v5 2/4] maintainers: claim maintainers of c11 atomics code Phil Yang
2020-05-26 9:01 ` [dpdk-dev] [PATCH v5 3/4] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-06-29 4:38 ` Honnappa Nagarahalli
2020-06-29 5:38 ` Phil Yang
2020-05-26 9:01 ` [dpdk-dev] [PATCH v5 4/4] eal/atomic: add wrapper for c11 atomic thread fence Phil Yang
2020-06-29 4:40 ` Honnappa Nagarahalli
2020-06-29 10:09 ` Ananyev, Konstantin
2020-06-29 14:37 ` Honnappa Nagarahalli
2020-06-29 10:13 ` Ananyev, Konstantin
2020-07-07 9:50 ` [dpdk-dev] [PATCH v6 0/4] generic rte atomic APIs deprecate proposal Phil Yang
2020-07-07 9:50 ` [dpdk-dev] [PATCH v6 1/4] doc: add generic atomic deprecation section Phil Yang
2020-07-10 16:55 ` Thomas Monjalon
2020-07-10 23:47 ` Honnappa Nagarahalli
2020-07-07 9:50 ` [dpdk-dev] [PATCH v6 2/4] maintainers: claim maintainers of C11 atomics Phil Yang
2020-07-10 17:45 ` Thomas Monjalon
2020-07-10 23:41 ` Honnappa Nagarahalli
2020-07-13 6:26 ` Phil Yang
2020-07-07 9:50 ` [dpdk-dev] [PATCH v6 3/4] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-07-07 9:50 ` [dpdk-dev] [PATCH v6 4/4] eal/atomic: add wrapper for C11 atomic thread fence Phil Yang
2020-07-13 6:23 ` [dpdk-dev] [PATCH v7 0/3] generic rte atomic APIs deprecate proposal Phil Yang
2020-07-13 6:23 ` [dpdk-dev] [PATCH v7 1/3] doc: add generic atomic deprecation section Phil Yang
2020-07-14 18:36 ` Honnappa Nagarahalli
2020-07-15 2:58 ` Phil Yang
2020-07-13 6:23 ` [dpdk-dev] [PATCH v7 2/3] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-07-13 6:23 ` [dpdk-dev] [PATCH v7 3/3] eal/atomic: add wrapper for C11 atomic thread fence Phil Yang
2020-07-16 4:53 ` [dpdk-dev] [PATCH v8 0/3] generic rte atomic APIs deprecate proposal Phil Yang
2020-07-16 4:53 ` [dpdk-dev] [PATCH v8 1/3] doc: add optimizations using C11 atomic built-ins Phil Yang
2020-07-16 10:35 ` David Marchand
2020-07-16 18:22 ` Honnappa Nagarahalli
2020-07-17 4:44 ` Phil Yang
2020-07-16 4:53 ` [dpdk-dev] [PATCH v8 2/3] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-07-16 10:48 ` David Marchand
2020-07-16 11:31 ` Thomas Monjalon
2020-07-16 16:37 ` Phil Yang
2020-07-16 16:42 ` Thomas Monjalon
2020-07-16 16:59 ` Honnappa Nagarahalli
2020-07-16 21:45 ` Stephen Hemminger
2020-07-17 22:48 ` Honnappa Nagarahalli
2020-07-18 2:18 ` Stephen Hemminger
2020-07-17 4:48 ` Phil Yang
2020-07-16 15:07 ` Phil Yang
2020-07-16 4:53 ` [dpdk-dev] [PATCH v8 3/3] eal/atomic: add wrapper for C11 atomic thread fence Phil Yang
2020-07-17 5:08 ` [dpdk-dev] [PATCH v9 0/3] generic rte atomic APIs deprecate proposal Phil Yang
2020-07-17 5:08 ` [dpdk-dev] [PATCH v9 1/3] doc: add optimizations using C11 atomic builtins Phil Yang
2020-07-17 5:08 ` [dpdk-dev] [PATCH v9 2/3] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-07-17 8:35 ` Thomas Monjalon
2020-07-17 9:41 ` Phil Yang
2020-07-17 5:08 ` [dpdk-dev] [PATCH v9 3/3] eal/atomic: add wrapper for C11 atomic thread fence Phil Yang
2020-07-17 8:48 ` Thomas Monjalon
2020-07-17 8:53 ` Phil Yang
2020-07-17 10:14 ` [dpdk-dev] [PATCH v10 0/3] generic rte atomic APIs deprecate proposal Phil Yang
2020-07-17 10:14 ` [dpdk-dev] [PATCH v10 1/3] doc: add optimizations using C11 atomic builtins Phil Yang
2020-07-17 10:14 ` [dpdk-dev] [PATCH v10 2/3] eal/atomic: add wrapper for C11 atomic thread fence Phil Yang
2020-07-17 10:14 ` [dpdk-dev] [PATCH v10 3/3] devtools: prevent use of rte atomic APIs in future patches Phil Yang
2020-07-17 13:58 ` [dpdk-dev] [PATCH v10 0/3] generic rte atomic APIs deprecate proposal David Marchand
2020-07-20 7:06 ` Phil Yang
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=BYAPR11MB314311EA8B6DBD782F76F529D7C70@BYAPR11MB3143.namprd11.prod.outlook.com \
--to=harry.van.haaren@intel.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=gavin.hu@arm.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=joyce.kong@arm.com \
--cc=konstantin.ananyev@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=nd@arm.com \
--cc=phil.yang@arm.com \
--cc=ruifeng.wang@arm.com \
--cc=stephen@networkplumber.org \
--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).