DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: nd <nd@arm.com>, Dharmik Thakkar <Dharmik.Thakkar@arm.com>,
	Malvika Gupta <Malvika.Gupta@arm.com>,
	"Gavin Hu (Arm Technology China)" <Gavin.Hu@arm.com>,
	nd <nd@arm.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [RFC 2/3] tqs: add thread quiescent state library
Date: Thu, 13 Dec 2018 07:39:30 +0000	[thread overview]
Message-ID: <AM6PR08MB36727D3C28BB5A6DEEC9B9AA98A00@AM6PR08MB3672.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258010D8B8CEE@IRSMSX106.ger.corp.intel.com>

> 
> 
> > > >
> > > > > > +
> > > > > > +/* Add a reader thread, running on an lcore, to the list of
> > > > > > +threads
> > > > > > + * reporting their quiescent state on a TQS variable.
> > > > > > + */
> > > > > > +int __rte_experimental
> > > > > > +rte_tqs_register_lcore(struct rte_tqs *v, unsigned int lcore_id) {
> > > > > > +	TQS_RETURN_IF_TRUE((v == NULL || lcore_id >=
> > > > > RTE_TQS_MAX_LCORE),
> > > > > > +				-EINVAL);
> > > > >
> > > > > It is not very good practice to make function return different
> > > > > values and behave in a different way in debug/non-debug mode.
> > > > > I'd say that for slow-path (functions in .c) it is always good
> > > > > to check input parameters.
> > > > > For fast-path (functions in .h) we sometimes skip such checking,
> > > > > but debug mode can probably use RTE_ASSERT() or so.
> > > > Makes sense, I will change this in the next version.
> > > >
> > > > >
> > > > >
> > > > > lcore_id >= RTE_TQS_MAX_LCORE
> > > > >
> > > > > Is this limitation really necessary?
> > > > I added this limitation because currently DPDK application cannot
> > > > take a mask more than 64bit wide. Otherwise, this should be as big
> > > > as
> > > RTE_MAX_LCORE.
> > > > I see that in the case of '-lcores' option, the number of lcores
> > > > can be more than the number of PEs. In this case, we still need a
> > > > MAX limit (but
> > > can be bigger than 64).
> > > >
> > > > > First it means that only lcores can use that API (at least
> > > > > data-path part), second even today many machines have more than 64
> cores.
> > > > > I think you can easily avoid such limitation, if instead of
> > > > > requiring lcore_id as input parameter, you'll just make it
> > > > > return index of
> > > next available entry in w[].
> > > > > Then tqs_update() can take that index as input parameter.
> > > > I had thought about a similar approach based on IDs. I was
> > > > concerned that ID will be one more thing to manage for the
> > > > application. But, I see the
> > > limitations of the current approach now. I will change it to allocation
> based.
> > > This will support even non-EAL pthreads as well.
> > >
> > > Yes, with such approach non-lcore threads will be able to use it also.
> > >
> > I realized that rte_tqs_register_lcore/ rte_tqs_unregister_lcore need
> > to be efficient as they can be called from the worker's packet
> > processing loop (rte_event_dequeue_burst allows blocking. So, the
> > worker thread needs to call rte_tqs_unregister_lcore before calling
> rte_event_dequeue_burst and rte_tqs_register_lcore before starting packet
> processing). Allocating the thread ID in these functions will make them more
> complex.
> >
> > I suggest that we change the argument 'lcore_id' to 'thread_id'. The
> > application could use 'lcore_id' as 'thread_id' if threads are mapped to
> physical cores 1:1.
> >
> > If the threads are not mapped 1:1 to physical cores, the threads need
> > to use a thread_id in the range of 0 - RTE_TQS_MAX_THREADS. I do not
> > see that DPDK has a thread_id concept. For TQS, the thread IDs are global
> (i.e. not per TQS variable). I could provide APIs to do the thread ID allocation,
> but I think the thread ID allocation should not be part of this library. Such
> thread ID might be useful for other libraries.
> 
> I don't think there is any point to introduce new thread_id concept just for
> that library.
Currently, we have rte_gettid API. It is being used by rte_spinlock. However, the thread ID returned here is the thread ID as defined by OS. rte_spinlock APIs do not care who defines the thread ID as long as those IDs are unique per thread. I think, if we have a thread_id concept that covers non-eal threads as well, it might help other libraries too. For ex: [1] talks about the limitation of per-lcore cache. I think this limitation can be removed easily if we could have a thread_id that is in a small, well defined space (rather than OS defined thread ID which may be an arbitrary number). I see similar issues mentioned for rte_timer.
It might be useful in the dynamic threads Bruce talked about at the Dublin summit (I am not sure on this one, just speculating).

[1] https://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#known-issue-label

> After all we already have a concept of lcore_id which pretty much serves the
> same purpose.
> I still think that we need to either:
> a) make register/unregister to work with any valid lcore_id (<=
> RTE_MAX_LCORE)
I have made this change already, it will be there in the next version.

> b) make register/unregister to return index in w[]
> 
> For a) will need mask bigger than 64bits.
> b)  would allow to use data-path API by non-lcores threads too, plus w[]
> would occupy less space, and check() might be faster.
> Though yes, as a drawback, for b) register/unregister probably would need
> extra 'while(CAS(...));' loop.
Along with the CAS, we also need to search for available index in the array.

> I suppose the question here do you foresee a lot of concurrent
> register/unregister at data-path?
IMO, yes, because of the event dev API being blocking.
We can solve this by providing separate APIs for allocation/freeing of the IDs. I am just questioning where these APIs should be.

> 
> >
> > <snip>
> >
> > >
> > > >
> > > > >
> > > > > > +
> > > > > > +		while (lcore_mask) {
> > > > > > +			l = __builtin_ctz(lcore_mask);
> > > > > > +			if (v->w[l].cnt != t)
> > > > > > +				break;
> > > > >
> > > > > As I understand, that makes control-path function progress
> > > > > dependent on simultaneous invocation of data-path functions.
> > > > I agree that the control-path function progress (for ex: how long
> > > > to wait for freeing the memory) depends on invocation of the
> > > > data-path functions. The separation of 'start', 'check' and the
> > > > option not to block in
> > > 'check' provide the flexibility for control-path to do some other
> > > work if it chooses to.
> > > >
> > > > > In some cases that might cause control-path to hang.
> > > > > Let say if data-path function wouldn't be called, or user
> > > > > invokes control-path and data-path functions from the same thread.
> > > > I agree with the case of data-path function not getting called. I
> > > > would consider that as programming error. I can document that
> > > > warning in
> > > the rte_tqs_check API.
> > >
> > > Sure, it can be documented.
> > > Though that means, that each data-path thread would have to do
> > > explicit
> > > update() call for every tqs it might use.
> > > I just think that it would complicate things and might limit usage
> > > of the library quite significantly.
> > Each data path thread has to report its quiescent state. Hence, each
> > data-path thread has to call update() (similar to how
> > rte_timer_manage() has to be called periodically on the worker thread).
> 
> I understand that.
> Though that means that each data-path thread has to know explicitly what rcu
> vars it accesses.
Yes. That is correct. It is both good and bad. It is providing flexibility to reduce the overhead. For ex: in pipeline mode, it may be that a particular data structure is accessed only by some of the threads in the application. In this case, this library allows for per data structure vars, which reduces the over head. This applies for service cores as well.

> Would be hard to adopt such API with rcu vars used inside some library.
> But ok, as I understand people do use QSBR approach in their apps and find it
> useful.
It can be adopted in the library with different levels of assumptions/constraints.
1) With the assumption that the data plane threads will update the quiescent state. For ex: for rte_hash library we could ask the user to pass the TQS variable as input and rte_hash writer APIs can call rte_tqs_start and rte_tqs_check APIs.
2) If the assumption in 1) is not good, updating of the quiescent state can be hidden in the library, but again with the assumption that the data plane library API is called on a regular basis. For ex: the rte_tqs_update can be called within rte_hash_lookup API.
3) If we do not want to assume that the data plane API will be called on a regular basis, then the rte_tqs_register/unregister APIs need to be used before and after entering the critical section along with calling rte_tqs_update API. For ex: rte_hash_lookup should have the sequence rte_tqs_register, <critical section>, rte_tqs_unregister, rte_tqs_update. (very similar to GP)

> 
> > Do you have any particular use case in mind where this fails?
> 
> Let say it means that library can't be used to add/del RX/TX ethdev callbacks
> in a safe manner.
I need to understand this better. I will look at rte_ethdev library.

> 
> BTW, two side questions:
> 1) As I understand what you propose is very similar to QSBR main concept.
> Wouldn't it be better to name it accordingly to avoid confusion (or at least
> document it somewhere).
> I think someone else already raised that question.
QSBR stands for Quiescent State Based Reclamation. This library already has 'Thread Quiescent State' in the name. Others have questioned/suggested why not use RCU instead. I called it thread quiescent state as this library just helps determine if all the readers have entered the quiescent state. It does not do anything else.

However, you are also bringing up an important point, 'will we add other methods of memory reclamation'? With that in mind, may be we should not call it RCU. But, may be call it as rte_rcu_qsbr_xxx? It will also future proof the API incase we want to add additional RCU types.

> 2) Would QSBR be the only technique in that lib?
> Any plans to add something similar to GP one too (with MBs at reader-side)?
I believe, by GP, you mean general-purpose RCU. In my understanding QSBR is the one with least overhead. For DPDK applications, I think reducing that overhead is important. The GP adds additional over head on the reader side. I did not see a need to add any additional ones as of now. But if there are use cases that cannot be achieved with the proposed APIs, we can definitely expand it.

> 
> >
> > >
> > > >
> > > > In the case of same thread calling both control-path and data-path
> > > > functions, it would depend on the sequence of the calls. The
> > > > following
> > > sequence should not cause any hangs:
> > > > Worker thread
> > > > 1) 'deletes' an entry from a lock-free data structure
> > > > 2) rte_tqs_start
> > > > 3) rte_tqs_update
> > > > 4) rte_tqs_check (wait == 1 or wait == 0)
> > > > 5) 'free' the entry deleted in 1)
> > >
> > > That an interesting idea, and that should help, I think.
> > > Probably worth to have {2,3,4} sequence as a new high level function.
> > >
> > Yes, this is a good idea. Such a function would be applicable only in
> > the worker thread. I would prefer to leave it to the application to take care.
> 
> Yes, it would be applicable only to worker thread, but why we can't have a
> function for it?
> Let say it could be 2 different functions: one doing {2,3,4} - for worker threads,
> and second doing just {2,4} - for control threads.
> Or it could be just one function that takes extra parameter: lcore_id/w[] index.
> If it is some predefined invalid value (-1 or so), step #3 will be skipped.
The rte_tqs_start and rte_tqs_check are separated into 2 APIs so that the writers do not have to spend CPU/memory cycles polling for the readers' quiescent state. In the context of DPDK, this overhead will be significant (at least equal to the length of 1 while loop on the worker core). This is one of the key features of this library. Combining 2,[3], 4 will defeat this purpose. For ex: in the rte_hash library, whenever a writer on the data path calls rte_hash_add, (with 2,3,4 combined) it will wait for the rest of the readers to enter quiescent state. i.e. the performance will come down whenever a rte_hash_add is called.

I am trying to understand your concern. If it is that, 'programmers may not use the right sequence', I would prefer to treat that as programming error. May be it is better addressed by providing debugging capabilities.

> 
> Konstantin

  reply	other threads:[~2018-12-13  7:39 UTC|newest]

Thread overview: 260+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22  3:30 [dpdk-dev] [RFC 0/3] " Honnappa Nagarahalli
2018-11-22  3:30 ` [dpdk-dev] [RFC 1/3] log: add TQS log type Honnappa Nagarahalli
2018-11-27 22:24   ` Stephen Hemminger
2018-11-28  5:58     ` Honnappa Nagarahalli
2018-11-22  3:30 ` [dpdk-dev] [RFC 2/3] tqs: add thread quiescent state library Honnappa Nagarahalli
2018-11-24 12:18   ` Ananyev, Konstantin
2018-11-27 21:32     ` Honnappa Nagarahalli
2018-11-28 15:25       ` Ananyev, Konstantin
2018-12-07  7:27         ` Honnappa Nagarahalli
2018-12-07 17:29           ` Stephen Hemminger
2018-12-11  6:40             ` Honnappa Nagarahalli
2018-12-13 12:26               ` Burakov, Anatoly
2018-12-18  4:30                 ` Honnappa Nagarahalli
2018-12-18  6:31                   ` Stephen Hemminger
2018-12-12  9:29           ` Ananyev, Konstantin
2018-12-13  7:39             ` Honnappa Nagarahalli [this message]
2018-12-17 13:14               ` Ananyev, Konstantin
2018-11-22  3:30 ` [dpdk-dev] [RFC 3/3] test/tqs: Add API and functional tests Honnappa Nagarahalli
     [not found] ` <CGME20181122073110eucas1p17592400af6c0b807dc87e90d136575af@eucas1p1.samsung.com>
2018-11-22  7:31   ` [dpdk-dev] [RFC 0/3] tqs: add thread quiescent state library Ilya Maximets
2018-11-27 22:28 ` Stephen Hemminger
2018-11-27 22:49   ` Van Haaren, Harry
2018-11-28  5:31     ` Honnappa Nagarahalli
2018-11-28 23:23       ` Stephen Hemminger
2018-11-30  2:13         ` Honnappa Nagarahalli
2018-11-30 16:26           ` Luca Boccassi
2018-11-30 18:32             ` Stephen Hemminger
2018-11-30 20:20             ` Honnappa Nagarahalli
2018-11-30 20:56           ` Mattias Rönnblom
2018-11-30 23:44             ` Stephen Hemminger
2018-12-01 18:37               ` Honnappa Nagarahalli
2018-11-30  2:25     ` Honnappa Nagarahalli
2018-11-30 21:03       ` Mattias Rönnblom
2018-12-22  2:14 ` [dpdk-dev] [RFC v2 0/2] rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2018-12-22  2:14   ` [dpdk-dev] [RFC v2 1/2] " Honnappa Nagarahalli
2019-01-15 11:39     ` Ananyev, Konstantin
2019-01-15 20:43       ` Honnappa Nagarahalli
2019-01-16 15:56         ` Ananyev, Konstantin
2019-01-18  6:48           ` Honnappa Nagarahalli
2019-01-18 12:14             ` Ananyev, Konstantin
2019-01-24 17:15               ` Honnappa Nagarahalli
2019-01-24 18:05                 ` Ananyev, Konstantin
2019-02-22  7:07                   ` Honnappa Nagarahalli
2018-12-22  2:14   ` [dpdk-dev] [RFC v2 2/2] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2018-12-23  7:30     ` Stephen Hemminger
2018-12-23 16:25       ` Paul E. McKenney
2019-01-18  7:04         ` Honnappa Nagarahalli
2019-02-22  7:04   ` [dpdk-dev] [RFC v3 0/5] rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-02-22  7:04     ` [dpdk-dev] [RFC v3 1/5] " Honnappa Nagarahalli
2019-02-22  7:04     ` [dpdk-dev] [RFC v3 2/5] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-02-22  7:04     ` [dpdk-dev] [RFC v3 3/5] lib/rcu: add dynamic memory allocation capability Honnappa Nagarahalli
2019-02-22  7:04     ` [dpdk-dev] [RFC v3 4/5] test/rcu_qsbr: modify test cases for dynamic memory allocation Honnappa Nagarahalli
2019-02-22  7:04     ` [dpdk-dev] [RFC v3 5/5] lib/rcu: fix the size of register thread ID array size Honnappa Nagarahalli
2019-03-19  4:52 ` [dpdk-dev] [PATCH 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-03-19  4:52   ` Honnappa Nagarahalli
2019-03-19  4:52   ` [dpdk-dev] [PATCH 1/3] rcu: " Honnappa Nagarahalli
2019-03-19  4:52     ` Honnappa Nagarahalli
2019-03-22 16:42     ` Ananyev, Konstantin
2019-03-22 16:42       ` Ananyev, Konstantin
2019-03-26  4:35       ` Honnappa Nagarahalli
2019-03-26  4:35         ` Honnappa Nagarahalli
2019-03-28 11:15         ` Ananyev, Konstantin
2019-03-28 11:15           ` Ananyev, Konstantin
2019-03-29  5:54           ` Honnappa Nagarahalli
2019-03-29  5:54             ` Honnappa Nagarahalli
2019-03-19  4:52   ` [dpdk-dev] [PATCH 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-03-19  4:52     ` Honnappa Nagarahalli
2019-03-19  4:52   ` [dpdk-dev] [PATCH 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-03-19  4:52     ` Honnappa Nagarahalli
2019-03-25 11:34     ` Kovacevic, Marko
2019-03-25 11:34       ` Kovacevic, Marko
2019-03-26  4:43       ` Honnappa Nagarahalli
2019-03-26  4:43         ` Honnappa Nagarahalli
2019-03-27  5:52 ` [dpdk-dev] [PATCH v2 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-03-27  5:52   ` Honnappa Nagarahalli
2019-03-27  5:52   ` [dpdk-dev] [PATCH v2 1/3] rcu: " Honnappa Nagarahalli
2019-03-27  5:52     ` Honnappa Nagarahalli
2019-03-27  5:52   ` [dpdk-dev] [PATCH v2 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-03-27  5:52     ` Honnappa Nagarahalli
2019-03-27  5:52   ` [dpdk-dev] [PATCH v2 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-03-27  5:52     ` Honnappa Nagarahalli
2019-04-01 17:10 ` [dpdk-dev] [PATCH v3 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-04-01 17:10   ` Honnappa Nagarahalli
2019-04-01 17:11   ` [dpdk-dev] [PATCH v3 1/3] rcu: " Honnappa Nagarahalli
2019-04-01 17:11     ` Honnappa Nagarahalli
2019-04-02 10:22     ` Ananyev, Konstantin
2019-04-02 10:22       ` Ananyev, Konstantin
2019-04-02 10:53       ` Ananyev, Konstantin
2019-04-02 10:53         ` Ananyev, Konstantin
2019-04-01 17:11   ` [dpdk-dev] [PATCH v3 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-04-01 17:11     ` Honnappa Nagarahalli
2019-04-02 10:55     ` Ananyev, Konstantin
2019-04-02 10:55       ` Ananyev, Konstantin
2019-04-01 17:11   ` [dpdk-dev] [PATCH v3 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-04-01 17:11     ` Honnappa Nagarahalli
2019-04-10 11:20 ` [dpdk-dev] [PATCH v4 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-04-10 11:20   ` Honnappa Nagarahalli
2019-04-10 11:20   ` [dpdk-dev] [PATCH v4 1/3] rcu: " Honnappa Nagarahalli
2019-04-10 11:20     ` Honnappa Nagarahalli
2019-04-10 18:14     ` Paul E. McKenney
2019-04-10 18:14       ` Paul E. McKenney
2019-04-11  4:35       ` Honnappa Nagarahalli
2019-04-11  4:35         ` Honnappa Nagarahalli
2019-04-11 15:26         ` Paul E. McKenney
2019-04-11 15:26           ` Paul E. McKenney
2019-04-12 20:21           ` Honnappa Nagarahalli
2019-04-12 20:21             ` Honnappa Nagarahalli
2019-04-15 16:51             ` Ananyev, Konstantin
2019-04-15 16:51               ` Ananyev, Konstantin
2019-04-15 19:46               ` Honnappa Nagarahalli
2019-04-15 19:46                 ` Honnappa Nagarahalli
2019-04-10 11:20   ` [dpdk-dev] [PATCH v4 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-04-10 11:20     ` Honnappa Nagarahalli
2019-04-10 15:26     ` Stephen Hemminger
2019-04-10 15:26       ` Stephen Hemminger
2019-04-10 16:15       ` Honnappa Nagarahalli
2019-04-10 16:15         ` Honnappa Nagarahalli
2019-04-10 11:20   ` [dpdk-dev] [PATCH v4 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-04-10 11:20     ` Honnappa Nagarahalli
2019-04-12 20:20 ` [dpdk-dev] [PATCH v5 0/3] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-04-12 20:20   ` Honnappa Nagarahalli
2019-04-12 20:20   ` [dpdk-dev] [PATCH v5 1/3] rcu: " Honnappa Nagarahalli
2019-04-12 20:20     ` Honnappa Nagarahalli
2019-04-12 22:06     ` Stephen Hemminger
2019-04-12 22:06       ` Stephen Hemminger
2019-04-12 22:24       ` Honnappa Nagarahalli
2019-04-12 22:24         ` Honnappa Nagarahalli
2019-04-12 23:06         ` Stephen Hemminger
2019-04-12 23:06           ` Stephen Hemminger
2019-04-15 12:24           ` Ananyev, Konstantin
2019-04-15 12:24             ` Ananyev, Konstantin
2019-04-15 15:38             ` Stephen Hemminger
2019-04-15 15:38               ` Stephen Hemminger
2019-04-15 17:39               ` Ananyev, Konstantin
2019-04-15 17:39                 ` Ananyev, Konstantin
2019-04-15 18:56                 ` Honnappa Nagarahalli
2019-04-15 18:56                   ` Honnappa Nagarahalli
2019-04-15 21:26                 ` Stephen Hemminger
2019-04-15 21:26                   ` Stephen Hemminger
2019-04-16  5:29                   ` Honnappa Nagarahalli
2019-04-16  5:29                     ` Honnappa Nagarahalli
2019-04-16 14:54                     ` Stephen Hemminger
2019-04-16 14:54                       ` Stephen Hemminger
2019-04-16 16:56                       ` Honnappa Nagarahalli
2019-04-16 16:56                         ` Honnappa Nagarahalli
2019-04-16 21:22                         ` Stephen Hemminger
2019-04-16 21:22                           ` Stephen Hemminger
2019-04-17  1:45                           ` Honnappa Nagarahalli
2019-04-17  1:45                             ` Honnappa Nagarahalli
2019-04-17 13:39                             ` Ananyev, Konstantin
2019-04-17 13:39                               ` Ananyev, Konstantin
2019-04-17 14:02                               ` Honnappa Nagarahalli
2019-04-17 14:02                                 ` Honnappa Nagarahalli
2019-04-17 14:18                               ` Thomas Monjalon
2019-04-17 14:18                                 ` Thomas Monjalon
2019-04-12 20:20   ` [dpdk-dev] [PATCH v5 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-04-12 20:20     ` Honnappa Nagarahalli
2019-04-12 20:20   ` [dpdk-dev] [PATCH v5 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-04-12 20:20     ` Honnappa Nagarahalli
2019-04-15 17:29   ` [dpdk-dev] [PATCH v5 0/3] lib/rcu: add RCU library supporting QSBR mechanism Ananyev, Konstantin
2019-04-15 17:29     ` Ananyev, Konstantin
2019-04-16  5:10     ` Honnappa Nagarahalli
2019-04-16  5:10       ` Honnappa Nagarahalli
2019-04-17  4:13 ` [dpdk-dev] [PATCH v6 " Honnappa Nagarahalli
2019-04-17  4:13   ` Honnappa Nagarahalli
2019-04-17  4:13   ` [dpdk-dev] [PATCH v6 1/3] rcu: " Honnappa Nagarahalli
2019-04-17  4:13     ` Honnappa Nagarahalli
2019-04-19 19:19     ` Paul E. McKenney
2019-04-19 19:19       ` Paul E. McKenney
2019-04-23  1:08       ` Honnappa Nagarahalli
2019-04-23  1:08         ` Honnappa Nagarahalli
2019-04-17  4:13   ` [dpdk-dev] [PATCH v6 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-04-17  4:13     ` Honnappa Nagarahalli
2019-04-17  4:13   ` [dpdk-dev] [PATCH v6 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-04-17  4:13     ` Honnappa Nagarahalli
2019-04-21 16:40   ` [dpdk-dev] [PATCH v6 0/3] lib/rcu: add RCU library supporting QSBR mechanism Thomas Monjalon
2019-04-21 16:40     ` Thomas Monjalon
2019-04-25 14:18     ` Honnappa Nagarahalli
2019-04-25 14:18       ` Honnappa Nagarahalli
2019-04-25 14:27       ` Honnappa Nagarahalli
2019-04-25 14:27         ` Honnappa Nagarahalli
2019-04-25 14:38       ` David Marchand
2019-04-25 14:38         ` David Marchand
2019-04-23  4:31 ` [dpdk-dev] [PATCH v7 " Honnappa Nagarahalli
2019-04-23  4:31   ` Honnappa Nagarahalli
2019-04-23  4:31   ` [dpdk-dev] [PATCH v7 1/3] rcu: " Honnappa Nagarahalli
2019-04-23  4:31     ` Honnappa Nagarahalli
2019-04-23  8:10     ` Paul E. McKenney
2019-04-23  8:10       ` Paul E. McKenney
2019-04-23 21:23       ` Honnappa Nagarahalli
2019-04-23 21:23         ` Honnappa Nagarahalli
2019-04-24 20:02         ` Jerin Jacob Kollanukkaran
2019-04-24 20:02           ` Jerin Jacob Kollanukkaran
2019-04-25  5:15           ` Honnappa Nagarahalli
2019-04-25  5:15             ` Honnappa Nagarahalli
2019-04-24 10:03     ` Ruifeng Wang (Arm Technology China)
2019-04-24 10:03       ` Ruifeng Wang (Arm Technology China)
2019-04-23  4:31   ` [dpdk-dev] [PATCH v7 2/3] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-04-23  4:31     ` Honnappa Nagarahalli
2019-04-23  4:31   ` [dpdk-dev] [PATCH v7 3/3] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-04-23  4:31     ` Honnappa Nagarahalli
2019-04-24 10:12     ` Ruifeng Wang (Arm Technology China)
2019-04-24 10:12       ` Ruifeng Wang (Arm Technology China)
2019-04-26  4:39 ` [dpdk-dev] [PATCH v8 0/4] lib/rcu: add RCU library supporting QSBR mechanism Honnappa Nagarahalli
2019-04-26  4:39   ` Honnappa Nagarahalli
2019-04-26  4:39   ` [dpdk-dev] [PATCH v8 1/4] rcu: " Honnappa Nagarahalli
2019-04-26  4:39     ` Honnappa Nagarahalli
2019-04-26  8:13     ` Jerin Jacob Kollanukkaran
2019-04-26  8:13       ` Jerin Jacob Kollanukkaran
2019-04-28  3:25     ` Ruifeng Wang (Arm Technology China)
2019-04-28  3:25       ` Ruifeng Wang (Arm Technology China)
2019-04-29 20:33       ` Thomas Monjalon
2019-04-29 20:33         ` Thomas Monjalon
2019-04-30 10:51         ` Hemant Agrawal
2019-04-30 10:51           ` Hemant Agrawal
2019-04-26  4:39   ` [dpdk-dev] [PATCH v8 2/4] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-04-26  4:39     ` Honnappa Nagarahalli
2019-04-29 20:35     ` Thomas Monjalon
2019-04-29 20:35       ` Thomas Monjalon
2019-04-30  4:20       ` Honnappa Nagarahalli
2019-04-30  4:20         ` Honnappa Nagarahalli
2019-04-30  7:58         ` Thomas Monjalon
2019-04-30  7:58           ` Thomas Monjalon
2019-04-26  4:39   ` [dpdk-dev] [PATCH v8 3/4] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-04-26  4:39     ` Honnappa Nagarahalli
2019-04-26  4:40   ` [dpdk-dev] [PATCH v8 4/4] doc: added RCU to the release notes Honnappa Nagarahalli
2019-04-26  4:40     ` Honnappa Nagarahalli
2019-04-26 12:04   ` [dpdk-dev] [PATCH v8 0/4] lib/rcu: add RCU library supporting QSBR mechanism Ananyev, Konstantin
2019-04-26 12:04     ` Ananyev, Konstantin
2019-05-01  3:54 ` [dpdk-dev] [PATCH v9 " Honnappa Nagarahalli
2019-05-01  3:54   ` Honnappa Nagarahalli
2019-05-01  3:54   ` [dpdk-dev] [PATCH v9 1/4] rcu: " Honnappa Nagarahalli
2019-05-01  3:54     ` Honnappa Nagarahalli
2019-05-01  3:54   ` [dpdk-dev] [PATCH v9 2/4] test/rcu_qsbr: add API and functional tests Honnappa Nagarahalli
2019-05-01  3:54     ` Honnappa Nagarahalli
2019-05-03 14:31     ` David Marchand
2019-05-03 14:31       ` David Marchand
2019-05-06 23:16       ` Honnappa Nagarahalli
2019-05-06 23:16         ` Honnappa Nagarahalli
2019-05-01  3:54   ` [dpdk-dev] [PATCH v9 3/4] doc/rcu: add lib_rcu documentation Honnappa Nagarahalli
2019-05-01  3:54     ` Honnappa Nagarahalli
2019-05-01 11:37     ` Mcnamara, John
2019-05-01 11:37       ` Mcnamara, John
2019-05-01 21:20       ` Honnappa Nagarahalli
2019-05-01 21:20         ` Honnappa Nagarahalli
2019-05-01 21:32         ` Thomas Monjalon
2019-05-01 21:32           ` Thomas Monjalon
2019-05-01  3:54   ` [dpdk-dev] [PATCH v9 4/4] doc: added RCU to the release notes Honnappa Nagarahalli
2019-05-01  3:54     ` Honnappa Nagarahalli
2019-05-01 11:31     ` Mcnamara, John
2019-05-01 11:31       ` Mcnamara, John
2019-05-01 12:15   ` [dpdk-dev] [PATCH v9 0/4] lib/rcu: add RCU library supporting QSBR mechanism Neil Horman
2019-05-01 12:15     ` Neil Horman
2019-05-01 14:56     ` Honnappa Nagarahalli
2019-05-01 14:56       ` Honnappa Nagarahalli
2019-05-01 18:05       ` Neil Horman
2019-05-01 18:05         ` Neil Horman
2019-05-01 21:18         ` Honnappa Nagarahalli
2019-05-01 21:18           ` Honnappa Nagarahalli
2019-05-01 23:36   ` Thomas Monjalon
2019-05-01 23:36     ` Thomas Monjalon

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=AM6PR08MB36727D3C28BB5A6DEEC9B9AA98A00@AM6PR08MB3672.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=Dharmik.Thakkar@arm.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Malvika.Gupta@arm.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=nd@arm.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).