From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>, "stephen@networkplumber.org" <stephen@networkplumber.org>, "paulmck@linux.ibm.com" <paulmck@linux.ibm.com> Cc: "Wang, Yipeng1" <yipeng1.wang@intel.com>, "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>, "Ruifeng Wang (Arm Technology China)" <Ruifeng.Wang@arm.com>, Dharmik Thakkar <Dharmik.Thakkar@arm.com>, "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>, nd <nd@arm.com>, nd <nd@arm.com> Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/ring: add peek API Date: Fri, 11 Oct 2019 14:41:01 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191975AE3@irsmsx105.ger.corp.intel.com> (raw) In-Reply-To: <VE1PR08MB5149D7CFDF83F656FBD1469098970@VE1PR08MB5149.eurprd08.prod.outlook.com> > -----Original Message----- > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] > Sent: Friday, October 11, 2019 6:04 AM > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; stephen@networkplumber.org; paulmck@linux.ibm.com > Cc: Wang, Yipeng1 <yipeng1.wang@intel.com>; Medvedkin, Vladimir <vladimir.medvedkin@intel.com>; Ruifeng Wang (Arm Technology > China) <Ruifeng.Wang@arm.com>; Dharmik Thakkar <Dharmik.Thakkar@arm.com>; dev@dpdk.org; nd <nd@arm.com>; nd > <nd@arm.com>; nd <nd@arm.com> > Subject: RE: [PATCH v3 1/3] lib/ring: add peek API > > > > > > <snip> > > > > > > > > > > > > > > > > > > > Subject: [PATCH v3 1/3] lib/ring: add peek API > > > > > > > > > > > > > > From: Ruifeng Wang <ruifeng.wang@arm.com> > > > > > > > > > > > > > > The peek API allows fetching the next available object in the > > > > > > > ring without dequeuing it. This helps in scenarios where > > > > > > > dequeuing of objects depend on their value. > > > > > > > > > > > > > > Signed-off-by: Dharmik Thakkar <dharmik.thakkar@arm.com> > > > > > > > Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com> > > > > > > > Reviewed-by: Honnappa Nagarahalli > > > > > > > <honnappa.nagarahalli@arm.com> > > > > > > > Reviewed-by: Gavin Hu <gavin.hu@arm.com> > > > > > > > --- > > > > > > > lib/librte_ring/rte_ring.h | 30 > > > > > > > ++++++++++++++++++++++++++++++ > > > > > > > 1 file changed, 30 insertions(+) > > > > > > > > > > > > > > diff --git a/lib/librte_ring/rte_ring.h > > > > > > > b/lib/librte_ring/rte_ring.h index 2a9f768a1..d3d0d5e18 100644 > > > > > > > --- a/lib/librte_ring/rte_ring.h > > > > > > > +++ b/lib/librte_ring/rte_ring.h > > > > > > > @@ -953,6 +953,36 @@ rte_ring_dequeue_burst(struct rte_ring > > > > > > > *r, void > > > > > > **obj_table, > > > > > > > r->cons.single, available); } > > > > > > > > > > > > > > +/** > > > > > > > + * Peek one object from a ring. > > > > > > > + * > > > > > > > + * The peek API allows fetching the next available object in > > > > > > > +the ring > > > > > > > + * without dequeuing it. This API is not multi-thread safe > > > > > > > +with respect > > > > > > > + * to other consumer threads. > > > > > > > + * > > > > > > > + * @param r > > > > > > > + * A pointer to the ring structure. > > > > > > > + * @param obj_p > > > > > > > + * A pointer to a void * pointer (object) that will be filled. > > > > > > > + * @return > > > > > > > + * - 0: Success, object available > > > > > > > + * - -ENOENT: Not enough entries in the ring. > > > > > > > + */ > > > > > > > +__rte_experimental > > > > > > > +static __rte_always_inline int rte_ring_peek(struct rte_ring > > > > > > > +*r, void **obj_p) > > > > > > > > > > > > As it is not MT safe, then I think we need _sc_ in the name, to > > > > > > follow other rte_ring functions naming conventions > > > > > > (rte_ring_sc_peek() or so). > > > > > Agree > > > > > > > > > > > > > > > > > As a better alternative what do you think about introducing a > > > > > > serialized versions of DPDK rte_ring dequeue functions? > > > > > > Something like that: > > > > > > > > > > > > /* same as original ring dequeue, but: > > > > > > * 1) move cons.head only if cons.head == const.tail > > > > > > * 2) don't update cons.tail > > > > > > */ > > > > > > unsigned int > > > > > > rte_ring_serial_dequeue_bulk(struct rte_ring *r, void > > > > > > **obj_table, unsigned int n, > > > > > > unsigned int *available); > > > > > > > > > > > > /* sets both cons.head and cons.tail to cons.head + num */ void > > > > > > rte_ring_serial_dequeue_finish(struct rte_ring *r, uint32_t > > > > > > num); > > > > > > > > > > > > /* resets cons.head to const.tail value */ void > > > > > > rte_ring_serial_dequeue_abort(struct rte_ring *r); > > > > > > > > > > > > Then your dq_reclaim cycle function will look like that: > > > > > > > > > > > > const uint32_t nb_elt = dq->elt_size/8 + 1; uint32_t avl, n; > > > > > > uintptr_t elt[nb_elt]; ... > > > > > > > > > > > > do { > > > > > > > > > > > > /* read next elem from the queue */ > > > > > > n = rte_ring_serial_dequeue_bulk(dq->r, elt, nb_elt, &avl); > > > > > > if (n == 0) > > > > > > break; > > > > > > > > > > > > /* wrong period, keep elem in the queue */ if > > > > > > (rte_rcu_qsbr_check(dr->v, > > > > > > elt[0]) != 1) { > > > > > > rte_ring_serial_dequeue_abort(dq->r); > > > > > > break; > > > > > > } > > > > > > > > > > > > /* can reclaim, remove elem from the queue */ > > > > > > rte_ring_serial_dequeue_finish(dr->q, nb_elt); > > > > > > > > > > > > /*call reclaim function */ > > > > > > dr->f(dr->p, elt); > > > > > > > > > > > > } while (avl >= nb_elt); > > > > > > > > > > > > That way, I think even rte_rcu_qsbr_dq_reclaim() can be MT safe. > > > > > > As long as actual reclamation callback itself is MT safe of course. > > > > > > > > > > I think it is a great idea. The other writers would still be > > > > > polling for the current writer to update the tail or update the > > > > > head. This makes it a > > > > blocking solution. > > > > > > > > Yep, it is a blocking one. > > > > > > > > > We can make the other threads not poll i.e. they will quit > > > > > reclaiming if they > > > > see that other writers are dequeuing from the queue. > > > > > > > > Actually didn't think about that possibility, but yes should be > > > > possible to have _try_ semantics too. > > > > > > > > >The other way is to use per thread queues. > > > > > > > > > > The other requirement I see is to support unbounded-size data > > > > > structures where in the data structures do not have a > > > > > pre-determined number of entries. Also, currently the defer queue > > > > > size is equal to the total > > > > number of entries in a given data structure. There are plans to > > > > support dynamically resizable defer queue. This means, memory > > > > allocation which will affect the lock-free-ness of the solution. > > > > > > > > > > So, IMO: > > > > > 1) The API should provide the capability to support different > > > > > algorithms - > > > > may be through some flags? > > > > > 2) The requirements for the ring are pretty unique to the problem > > > > > we have here (for ex: move the cons-head only if cons-tail is also > > > > > the same, skip > > > > polling). So, we should probably implement a ring with-in the RCU library? > > > > > > > > Personally, I think such serialization ring API would be useful for > > > > other cases too. > > > > There are few cases when user need to read contents of the queue > > > > without removing elements from it. > > > > Let say we do use similar approach inside TLDK to implement TCP > > > > transmit queue. > > > > If such API would exist in DPDK we can just use it straightway, > > > > without maintaining a separate one. > > > ok > > > > > > > > > > > > > > > > > From the timeline perspective, adding all these capabilities would > > > > > be difficult to get done with in 19.11 timeline. What I have here > > > > > satisfies my current needs. I suggest that we make provisions in > > > > > APIs now to > > > > support all these features, but do the implementation in the coming > > releases. > > > > Does this sound ok for you? > > > > > > > > Not sure I understand your suggestion here... > > > > Could you explain it a bit more - how new API will look like and > > > > what would be left for the future. > > > For this patch, I suggest we do not add any more complexity. If > > > someone wants a lock-free/block-free mechanism, it is available by creating > > per thread defer queues. > > > > > > We push the following to the future: > > > 1) Dynamically size adjustable defer queue. IMO, with this, the > > > lock-free/block-free reclamation will not be available (memory allocation > > requires locking). The memory for the defer queue will be allocated/freed in > > chunks of 'size' elements as the queue grows/shrinks. > > > > That one is fine by me. > > In fact I don't know would be there a real use-case for dynamic defer queue > > for rcu var... > > But I suppose that's subject for another discussion. > Currently, the defer queue size is equal to the number of resources in the data structure. This is unnecessary as the reclamation is done > regularly. > If a smaller queue size is used, the queue might get full (even after reclamation), in which case, the queue size should be increased. I understand the intention. Though I am not very happy with approach where to free one resource we first have to allocate another one. Sounds like a source of deadlocks and for that case probably unnecessary complication. But again, as it is not for 19.11 we don't have to discuss it now. > > > > > > > > 2) Constant size defer queue with lock-free and block-free reclamation > > > (single option). The defer queue will be of fixed length 'size'. If > > > the queue gets full an error is returned. The user could provide a 'size' equal > > to the number of elements in a data structure to ensure queue never gets full. > > > > Ok so for 19.11 what enqueue/dequeue model do you plan to support? > > - MP/MC > > - MP/SC > > - SP/SC > Just SP/SC Ok, just to confirm we are on the same page: there would be a possibility for one thread do dq_enqueue(), second one do dq_reclaim() simultaneously (of course if actual reclamation function is thread safe)? > > - non MT at all (only same single thread can do enqueue and dequeue) > If MT safe is required, one should use 1 defer queue per thread for now. > > > > > And related question: > > What additional rte_ring API you plan to introduce in that case? > > - None > > - rte_ring_sc_peek() > rte_ring_peek will be changed to rte_ring_sc_peek > > > - rte_ring_serial_dequeue() > > > > > > > > I would add a 'flags' field in rte_rcu_qsbr_dq_parameters and provide > > > 2 #defines, one for dynamically variable size defer queue and the other for > > constant size defer queue. > > > > > > However, IMO, using per thread defer queue is a much simpler way to > > achieve 2. It does not add any significant burden to the user either. > > > > > > > > > > > > > > > > > > > > > > > > > +{ > > > > > > > + uint32_t prod_tail = r->prod.tail; > > > > > > > + uint32_t cons_head = r->cons.head; > > > > > > > + uint32_t count = (prod_tail - cons_head) & r->mask; > > > > > > > + unsigned int n = 1; > > > > > > > + if (count) { > > > > > > > + DEQUEUE_PTRS(r, &r[1], cons_head, obj_p, n, void *); > > > > > > > + return 0; > > > > > > > + } > > > > > > > + return -ENOENT; > > > > > > > +} > > > > > > > + > > > > > > > #ifdef __cplusplus > > > > > > > } > > > > > > > #endif > > > > > > > -- > > > > > > > 2.17.1
next prev parent reply other threads:[~2019-10-11 14:41 UTC|newest] Thread overview: 137+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-22 6:34 [dpdk-dev] [RFC PATCH 0/3] RCU integration with LPM library Ruifeng Wang 2019-08-22 6:34 ` [dpdk-dev] [RFC PATCH 1/3] doc/rcu: add RCU integration design details Ruifeng Wang 2019-08-22 6:34 ` [dpdk-dev] [RFC PATCH 2/3] lib/ring: add peek API Ruifeng Wang 2019-08-22 6:34 ` [dpdk-dev] [RFC PATCH 3/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2019-08-23 1:23 ` Stephen Hemminger 2019-08-26 3:11 ` Ruifeng Wang (Arm Technology China) 2019-08-26 5:32 ` Honnappa Nagarahalli 2019-08-22 15:52 ` [dpdk-dev] [RFC PATCH 0/3] RCU integration with LPM library Honnappa Nagarahalli 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 0/6] " Ruifeng Wang 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 1/6] doc/rcu: add RCU integration design details Ruifeng Wang 2019-09-06 19:44 ` Honnappa Nagarahalli 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 2/6] lib/ring: add peek API Ruifeng Wang 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 3/6] lib/lpm: integrate RCU QSBR Ruifeng Wang 2019-09-06 19:44 ` Honnappa Nagarahalli 2019-09-18 16:15 ` Medvedkin, Vladimir 2019-09-19 6:17 ` Ruifeng Wang (Arm Technology China) 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 4/6] app/test: add test case for LPM RCU integration Ruifeng Wang 2019-09-06 19:45 ` Honnappa Nagarahalli 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 5/6] test/lpm: reset total time Ruifeng Wang 2019-09-18 16:17 ` Medvedkin, Vladimir 2019-09-19 6:22 ` Ruifeng Wang (Arm Technology China) 2019-09-06 9:45 ` [dpdk-dev] [PATCH v2 6/6] test/lpm: add RCU integration performance tests Ruifeng Wang 2019-09-06 19:46 ` Honnappa Nagarahalli 2019-10-01 6:29 ` [dpdk-dev] [PATCH v3 0/3] Add RCU reclamation APIs Honnappa Nagarahalli 2019-10-01 6:29 ` [dpdk-dev] [PATCH v3 1/3] lib/ring: add peek API Honnappa Nagarahalli 2019-10-02 18:42 ` Ananyev, Konstantin 2019-10-03 19:49 ` Honnappa Nagarahalli 2019-10-07 9:01 ` Ananyev, Konstantin 2019-10-09 4:25 ` Honnappa Nagarahalli 2019-10-10 15:09 ` Ananyev, Konstantin 2019-10-11 5:03 ` Honnappa Nagarahalli 2019-10-11 14:41 ` Ananyev, Konstantin [this message] 2019-10-11 18:28 ` Honnappa Nagarahalli 2019-10-13 20:09 ` Ananyev, Konstantin 2019-10-14 4:11 ` Honnappa Nagarahalli 2019-10-01 6:29 ` [dpdk-dev] [PATCH v3 2/3] lib/rcu: add resource reclamation APIs Honnappa Nagarahalli 2019-10-02 17:39 ` Ananyev, Konstantin 2019-10-03 6:29 ` Honnappa Nagarahalli 2019-10-03 12:26 ` Ananyev, Konstantin 2019-10-04 6:07 ` Honnappa Nagarahalli 2019-10-07 10:46 ` Ananyev, Konstantin 2019-10-13 4:35 ` Honnappa Nagarahalli 2019-10-02 18:50 ` Ananyev, Konstantin 2019-10-03 6:42 ` Honnappa Nagarahalli 2019-10-03 11:52 ` Ananyev, Konstantin 2019-10-04 19:01 ` Medvedkin, Vladimir 2019-10-07 13:11 ` Medvedkin, Vladimir 2019-10-13 3:02 ` Honnappa Nagarahalli 2019-10-15 16:48 ` Medvedkin, Vladimir 2019-10-18 3:47 ` Honnappa Nagarahalli 2019-10-01 6:29 ` [dpdk-dev] [PATCH v3 3/3] doc/rcu: add RCU integration design details Honnappa Nagarahalli 2020-03-29 20:57 ` [dpdk-dev] [PATCH v3 0/3] Add RCU reclamation APIs Thomas Monjalon 2020-03-30 17:37 ` Honnappa Nagarahalli 2020-04-03 18:41 ` [dpdk-dev] [PATCH v4 0/4] " Honnappa Nagarahalli 2020-04-03 18:41 ` [dpdk-dev] [PATCH v4 1/4] lib/rcu: add resource " Honnappa Nagarahalli 2020-04-07 17:39 ` Ananyev, Konstantin 2020-04-19 23:22 ` Honnappa Nagarahalli 2020-04-20 8:19 ` Ananyev, Konstantin 2020-04-03 18:41 ` [dpdk-dev] [PATCH v4 2/4] test/rcu: test cases for RCU defer queue APIs Honnappa Nagarahalli 2020-04-03 18:41 ` [dpdk-dev] [PATCH v4 3/4] doc/rcu: add RCU integration design details Honnappa Nagarahalli 2020-04-03 18:41 ` [dpdk-dev] [PATCH v4 4/4] lib/rcu: add additional debug logs Honnappa Nagarahalli 2020-04-22 3:30 ` [dpdk-dev] [PATCH v5 0/4] Add RCU reclamation APIs Honnappa Nagarahalli 2020-04-22 3:30 ` [dpdk-dev] [PATCH v5 1/4] lib/rcu: add resource " Honnappa Nagarahalli 2020-04-22 8:36 ` Ananyev, Konstantin 2020-04-22 8:42 ` David Marchand 2020-04-22 8:51 ` David Marchand 2020-04-22 9:26 ` Ananyev, Konstantin 2020-04-22 3:30 ` [dpdk-dev] [PATCH v5 2/4] test/rcu: test cases for RCU defer queue APIs Honnappa Nagarahalli 2020-04-22 8:27 ` Ananyev, Konstantin 2020-04-22 3:30 ` [dpdk-dev] [PATCH v5 3/4] doc/rcu: add RCU integration design details Honnappa Nagarahalli 2020-04-22 3:30 ` [dpdk-dev] [PATCH v5 4/4] lib/rcu: add additional debug logs Honnappa Nagarahalli 2020-04-22 8:25 ` Ananyev, Konstantin 2020-04-22 18:46 ` [dpdk-dev] [PATCH v5 0/4] Add RCU reclamation APIs David Marchand 2019-10-01 18:28 ` [dpdk-dev] [PATCH v3 0/3] RCU integration with LPM library Honnappa Nagarahalli 2019-10-01 18:28 ` [dpdk-dev] [PATCH v3 1/3] lib/lpm: integrate RCU QSBR Honnappa Nagarahalli 2019-10-04 16:05 ` Medvedkin, Vladimir 2019-10-09 3:48 ` Honnappa Nagarahalli 2019-10-07 9:21 ` Ananyev, Konstantin 2019-10-13 4:36 ` Honnappa Nagarahalli 2019-10-15 11:15 ` Ananyev, Konstantin 2019-10-18 3:32 ` Honnappa Nagarahalli 2019-10-01 18:28 ` [dpdk-dev] [PATCH v3 2/3] app/test: add test case for LPM RCU integration Honnappa Nagarahalli 2019-10-01 18:28 ` [dpdk-dev] [PATCH v3 3/3] test/lpm: add RCU integration performance tests Honnappa Nagarahalli 2019-10-02 13:02 ` Aaron Conole 2019-10-03 9:09 ` Bruce Richardson 2020-06-08 5:16 ` [dpdk-dev] [PATCH v4 0/3] RCU integration with LPM library Ruifeng Wang 2020-06-08 5:16 ` [dpdk-dev] [PATCH v4 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-06-08 18:46 ` Honnappa Nagarahalli 2020-06-18 17:36 ` Medvedkin, Vladimir 2020-06-18 17:21 ` Medvedkin, Vladimir 2020-06-22 5:46 ` Ruifeng Wang 2020-06-23 4:34 ` Honnappa Nagarahalli 2020-06-08 5:16 ` [dpdk-dev] [PATCH v4 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-06-08 5:16 ` [dpdk-dev] [PATCH v4 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-06-29 8:02 ` [dpdk-dev] [PATCH v5 0/3] RCU integration with LPM library Ruifeng Wang 2020-06-29 8:02 ` [dpdk-dev] [PATCH v5 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-06-29 11:56 ` David Marchand 2020-06-29 12:55 ` Bruce Richardson 2020-06-30 10:35 ` Kinsella, Ray 2020-07-03 7:43 ` David Marchand 2020-07-04 17:00 ` Ruifeng Wang 2020-06-30 10:33 ` Kinsella, Ray 2020-06-29 8:02 ` [dpdk-dev] [PATCH v5 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-06-29 8:03 ` [dpdk-dev] [PATCH v5 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-07-07 14:40 ` [dpdk-dev] [PATCH v6 0/3] RCU integration with LPM library Ruifeng Wang 2020-07-07 14:40 ` [dpdk-dev] [PATCH v6 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-07-07 14:40 ` [dpdk-dev] [PATCH v6 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-07-07 14:40 ` [dpdk-dev] [PATCH v6 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-07-07 15:15 ` [dpdk-dev] [PATCH v7 0/3] RCU integration with LPM library Ruifeng Wang 2020-07-07 15:15 ` [dpdk-dev] [PATCH v7 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-07-08 12:36 ` Medvedkin, Vladimir 2020-07-08 14:30 ` David Marchand 2020-07-08 15:34 ` Ruifeng Wang 2020-07-07 15:15 ` [dpdk-dev] [PATCH v7 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-07-08 12:37 ` Medvedkin, Vladimir 2020-07-08 14:00 ` Ruifeng Wang 2020-07-07 15:15 ` [dpdk-dev] [PATCH v7 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-07-08 12:37 ` Medvedkin, Vladimir 2020-07-08 14:07 ` Ruifeng Wang 2020-07-09 8:02 ` [dpdk-dev] [PATCH v8 0/3] RCU integration with LPM library Ruifeng Wang 2020-07-09 8:02 ` [dpdk-dev] [PATCH v8 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-07-09 11:49 ` David Marchand 2020-07-09 14:35 ` Ruifeng Wang 2020-07-09 8:02 ` [dpdk-dev] [PATCH v8 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-07-09 8:02 ` [dpdk-dev] [PATCH v8 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-07-09 15:42 ` [dpdk-dev] [PATCH v9 0/3] RCU integration with LPM library Ruifeng Wang 2020-07-09 15:42 ` [dpdk-dev] [PATCH v9 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-07-09 15:42 ` [dpdk-dev] [PATCH v9 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-07-09 15:42 ` [dpdk-dev] [PATCH v9 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-07-10 2:22 ` [dpdk-dev] [PATCH v10 0/3] RCU integration with LPM library Ruifeng Wang 2020-07-10 2:22 ` [dpdk-dev] [PATCH v10 1/3] lib/lpm: integrate RCU QSBR Ruifeng Wang 2020-07-10 2:29 ` Ruifeng Wang 2020-07-10 2:22 ` [dpdk-dev] [PATCH v10 2/3] test/lpm: add LPM RCU integration functional tests Ruifeng Wang 2020-07-10 2:22 ` [dpdk-dev] [PATCH v10 3/3] test/lpm: add RCU integration performance tests Ruifeng Wang 2020-07-10 2:29 ` Ruifeng Wang 2020-07-10 12:21 ` [dpdk-dev] [PATCH v10 0/3] RCU integration with LPM library David Marchand 2020-07-10 14:34 ` Ruifeng Wang
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=2601191342CEEE43887BDE71AB9772580191975AE3@irsmsx105.ger.corp.intel.com \ --to=konstantin.ananyev@intel.com \ --cc=Dharmik.Thakkar@arm.com \ --cc=Honnappa.Nagarahalli@arm.com \ --cc=Ruifeng.Wang@arm.com \ --cc=dev@dpdk.org \ --cc=nd@arm.com \ --cc=paulmck@linux.ibm.com \ --cc=stephen@networkplumber.org \ --cc=vladimir.medvedkin@intel.com \ --cc=yipeng1.wang@intel.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
DPDK patches and discussions This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \ dev@dpdk.org public-inbox-index dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git