From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.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>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
nd <nd@arm.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/ring: add peek API
Date: Wed, 9 Oct 2019 04:25:37 +0000 [thread overview]
Message-ID: <VE1PR08MB5149988C9B8B2E9A556C5EAE98950@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772580191971EBE@irsmsx105.ger.corp.intel.com>
<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.
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.
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-09 4:25 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 [this message]
2019-10-10 15:09 ` Ananyev, Konstantin
2019-10-11 5:03 ` Honnappa Nagarahalli
2019-10-11 14:41 ` Ananyev, Konstantin
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=VE1PR08MB5149988C9B8B2E9A556C5EAE98950@VE1PR08MB5149.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Dharmik.Thakkar@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
--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
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).