From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
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>,
Gavin Hu <Gavin.Hu@arm.com>, Ruifeng Wang <Ruifeng.Wang@arm.com>,
Joyce Kong <Joyce.Kong@arm.com>, nd <nd@arm.com>,
"stable@dpdk.org" <stable@dpdk.org>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v3 09/12] service: avoid race condition for MT unsafe service
Date: Thu, 9 Apr 2020 01:31:56 +0000 [thread overview]
Message-ID: <AM6PR08MB4644AD62E177324970AD749F98C10@AM6PR08MB4644.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <BYAPR11MB31431BFA916927D037D05122D7C00@BYAPR11MB3143.namprd11.prod.outlook.com>
<snip>
> >
> > > > Subject: [PATCH v3 09/12] service: avoid race condition for MT
> > > > unsafe service
> > > >
> > > > From: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > >
> > > > There has possible that a MT unsafe service might get configured
> > > > to run on another core while the service is running currently.
> > > > This might result in the MT unsafe service running on multiple
> > > > cores simultaneously. Use 'execute_lock' always when the service
> > > > is MT unsafe.
> > > >
> > > > Fixes: e9139a32f6e8 ("service: add function to run on app lcore")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > Reviewed-by: Phil Yang <phil.yang@arm.com>
> > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > >
> > > We should put "fix" in the title, once converged on an implementation.
> > Ok, will replace 'avoid' with 'fix' (once we agree on the solution)
> >
> > >
> > > Regarding Fixes and stable backport, we should consider if fixing
> > > this in
> > stable
> > > with a performance degradation, fixing with more complex solution,
> > > or documenting a known issue a better solution.
> > >
> > >
> > > This fix (always taking the atomic lock) will have a negative
> > > performance impact on existing code using services. We should
> > > investigate a way to fix
> > it
> > > without causing datapath performance degradation.
> > Trying to gauge the impact on the existing applications...
> > The documentation does not explicitly disallow run time mapping of
> > cores to service.
> > 1) If the applications are mapping the cores to services at run time,
> > they are running with a bug. IMO, bug fix resulting in a performance
> > drop should be acceptable.
> > 2) If the service is configured to run on single core
> > (num_mapped_cores == 1), but service is set to MT unsafe - this will
> > have a (possible) performance impact.
> > a) This can be solved by setting the service to MT safe and can be
> > documented. This might be a reasonable solution for applications which
> > are compiling with
> > future DPDK releases.
> > b) We can also solve this using symbol versioning - the old version
> > of this function will use the old code, the new version of this
> > function will use the code in
> > this patch. So, if the application is run with
> > future DPDK releases without recompiling, it will continue to use the
> > old version. If the application is compiled
> > with future releases, they can use solution in 2a.
> > We also should think if this is an appropriate solution as this would
> > force 1) to recompile to get the fix.
> > 3) If the service is configured to run on multiple cores
> > (num_mapped_cores > 1), then for those applications, the lock is being
> > taken already. These applications might see some improvements as this
> > patch removes few instructions.
> >
> > >
> > > I think there is a way to achieve this by moving more checks/time to
> > > the control path (lcore updating the map), and not forcing the
> > > datapath lcore to always take an atomic.
> > I think 2a above is the solution.
>
> 2a above is e.g. the Eventdev SW routines like Rx/Tx scheduler services.
I scanned through the code briefly
I see that Eth RX/TX, Crypto adapters are setting the MT_SAFE capabilities, can be ignored.
Timer adaptor and some others do not set MT_SAFE. Seems like the cores to run on are mapped during run time. But it is not clear to me if it can get mapped to run on multiple cores. If they are, they are running with the bug.
But, these are all internal to DPDK and can be fixed.
Are there no performance tests in these components that we can run?
> We should strive to not reduce datapath performance at all here.
>
>
> > > In this particular case, we have a counter for number of iterations
> > > that a
> > Which counter are you thinking about?
> > All the counters I checked are not atomic operations currently. If we
> > are going to use counters they have to be atomic, which means
> > additional cycles in the data path.
>
> I'll try to explain the concept better, take this example:
> - One service core is mapped to a MT_UNSAFE service, like event/sw pmd
> - Application wants to map a 2nd lcore to the same service
> - You point out that today there is a race over the lock
> -- the lock is not taken if (num_mapped_lcores == 1)
> -- this avoids an atomic lock/unlock on the datapath
>
> To achieve our desired goal;
> - control thread doing mapping performs the following operations
> -- write service->num_mapped_lcores++ (atomic not required, only single-
> writer allowed by APIs)
This has to be atomic because of rte_service_run_iter_on_app_lcore API. Performance should be fine as this API is not called frequently. But need to consider the implications of more than one thread updating num_mapped_cores.
> -- MFENCE (full st-ld barrier) to flush write, and force later loads to issue
> after
I am not exactly sure what MFENCE on x86 does. On Arm platforms, the full barrier (DMB ISH) just makes sure that memory operations are not re-ordered around it. It does not say anything about when that store is visible to other cores. It will be visible at some point in time to cores.
But, I do not think we need to be worried about flushing to memory.
> -- read the "calls_per_service" counter for each lcores, add them up.
This can be trimmed down to the single core the service is mapped to currently, no need to add all the counters.
> ---- Wait :)
> -- re-read the "calls_per_service", and ensure the count has changed.
Basically, polling. This causes more traffic on the interconnect between the cores. But might be ok since this API might not be called frequently.
> ---- The fact that the calls_per_service has changed ensures the service-
> lcore
> has seen the new "num_mapped_cores" value, and has now taken the
> lock!
> -- *now* it is safe to map the 2nd lcore to the service
>
> There is a caveat here that the increments to the "calls_per_service" variable
> must become globally-observable. To force this immediately would require a
> write memory barrier, which could impact datapath performance. Given the
> service is now taking a lock, the unlock() thereof would ensure the
> "calls_per_service"
> is flushed to memory.
If we increment this variable only when the lock is held, we should be fine. We could have a separate variable.
>
> Note: we could use calls_per_service, or add a new variable to the service
> struct.
> Writes to this do not need to be atomic, as it is either mapped to a single core,
> or else there's a lock around it.
I think it is better to have a separate variable that is updated only when the lock is held.
I do not see any change in API sequence. We do this hand-shake only if the service is running (which is all controlled in the writer thread), correct?
This does not solve the problem with rte_service_run_iter_on_app_lcore getting called on multiple cores concurrently for the same service.
>
>
> > > service has done. If this increments we know that the lcore running
> > > the service has re-entered the critical section, so would see an
> > > updated "needs atomic" flag.
> > >
> > > This approach may introduce a predictable branch on the datapath,
> > > however the cost of a predictable branch vs always taking an atomic
> > > is order(s?) of magnitude, so a branch is much preferred.
> > >
> > > It must be possible to avoid the datapath overhead using a scheme like
> this.
> > It
> > > will likely be more complex than your proposed change below, however
> > > if it avoids datapath performance drops I feel that a more complex
> > > solution is worth investigating at least.
>
> > I do not completely understand the approach you are proposing, may be
> > you can elaborate more.
>
> Expanded above, showing a possible solution that does not require additional
> atomics on the datapath.
>
>
> > But, it seems to be based on a counter approach. Following is my
> > assessment on what happens if we use a counter. Let us say we kept
> > track of how many cores are running the service currently. We need an
> > atomic counter other than 'num_mapped_cores'. Let us call that counter
> 'num_current_cores'.
> > The code to call the service would look like below.
> >
> > 1) rte_atomic32_inc(&num_current_cores); /* this results in a full
> > memory barrier */
> > 2) if (__atomic_load_n(&num_current_cores, __ATOMIC_ACQUIRE) == 1) {
> > /* rte_atomic_read is not enough here as it does not provide the
> > required memory barrier for any architecture */
> > 3) run_service(); /* Call the service */
> > 4) }
> > 5) rte_atomic32_sub(&num_current_cores); /* Calling rte_atomic32_clear
> > is not enough as it is not an atomic operation and does not provide
> > the required memory barrier */
> >
> > But the above code has race conditions in lines 1 and 2. It is
> > possible that none of the cores will ever get to run the service as
> > they all could simultaneously increment the counter. Hence lines 1 and
> > 2 together need to be atomic, which is nothing but 'compare-exchange'
> operation.
> >
> > BTW, the current code has a bug where it calls 'rte_atomic_clear(&s-
> > >execute_lock)', it is missing memory barriers which results in
> > >clearing the
> > execute_lock before the service has completed running. I suggest
> > changing the 'execute_lock' to rte_spinlock_t and using
> > rte_spinlock_try_lock and rte_spinlock_unlock APIs.
>
> I don't think a spinlock is what we want here:
>
> The idea is that a service-lcore can be mapped to multiple services.
> If one service is already being run (by another thread), we do not want to spin
> here waiting for it to become "free" to run by this thread, it should continue
> to the next service that it is mapped to.
Agree. I am suggesting to use 'rte_spinlock_try_lock' (does not spin) which is nothing but 'compare-exchange'. Since the API is available, we should make use of it instead of repeating the code.
>
>
> > >
> > > A unit test is required to validate a fix like this - although
> > > perhaps found
> > by
> > > inspection/review, a real-world test to validate would give confidence.
> > Agree, need to have a test case.
> >
> > >
> > >
> > > Thoughts on such an approach?
> > >
> <snip patch contents>
next prev parent reply other threads:[~2020-04-09 1:32 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 [this message]
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
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=AM6PR08MB4644AD62E177324970AD749F98C10@AM6PR08MB4644.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Gavin.Hu@arm.com \
--cc=Joyce.Kong@arm.com \
--cc=Phil.Yang@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=nd@arm.com \
--cc=stable@dpdk.org \
--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).