* [dpdk-dev] [PATCH v4] rte_ring: clarify preemptible nature of ring algorithm
@ 2018-07-17 4:52 Honnappa Nagarahalli
2018-08-03 15:09 ` Olivier Matz
0 siblings, 1 reply; 3+ messages in thread
From: Honnappa Nagarahalli @ 2018-07-17 4:52 UTC (permalink / raw)
To: honnappa.nagarahalli, olivier.matz, anatoly.burakov; +Cc: dev, nd
rte_ring implementation is not preemptible only under certain
circumstances. This clarification is helpful for data plane and
control plane communication using rte_ring.
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
---
v4:
* Undo few changes (Anatoly, Oliver)
v3:
* Corrected known issues for rte_ring
* Referred to known issues in rte_ring.h (Anatoly, Oliver)
v2:
* Fixed checkpatch warnings
doc/guides/prog_guide/env_abstraction_layer.rst | 12 ++++++++----
lib/librte_ring/rte_ring.h | 5 +++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index a22640d..99d259f 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -445,13 +445,17 @@ Known Issues
Bypassing this constraint may cause the 2nd pthread to spin until the 1st one is scheduled again.
Moreover, if the 1st pthread is preempted by a context that has an higher priority, it may even cause a dead lock.
- This does not mean it cannot be used, simply, there is a need to narrow down the situation when it is used by multi-pthread on the same core.
+ This means, use cases involving preemptible pthreads should consider using rte_ring carefully.
- 1. It CAN be used for any single-producer or single-consumer situation.
+ 1. It CAN be used for preemptible single-producer and single-consumer use case.
- 2. It MAY be used by multi-producer/consumer pthread whose scheduling policy are all SCHED_OTHER(cfs). User SHOULD be aware of the performance penalty before using it.
+ 2. It CAN be used for non-preemptible multi-producer and preemptible single-consumer use case.
- 3. It MUST not be used by multi-producer/consumer pthreads, whose scheduling policies are SCHED_FIFO or SCHED_RR.
+ 3. It CAN be used for preemptible single-producer and non-preemptible multi-consumer use case.
+
+ 4. It MAY be used by preemptible multi-producer and/or preemptible multi-consumer pthreads whose scheduling policy are all SCHED_OTHER(cfs), SCHED_IDLE or SCHED_BATCH. User SHOULD be aware of the performance penalty before using it.
+
+ 5. It MUST not be used by multi-producer/consumer pthreads, whose scheduling policies are SCHED_FIFO or SCHED_RR.
+ rte_timer
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index 1245822..e680101 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -26,8 +26,9 @@
* - Bulk dequeue.
* - Bulk enqueue.
*
- * Note: the ring implementation is not preemptable. A lcore must not
- * be interrupted by another task that uses the same ring.
+ * Note: the ring implementation is not preemptible. Refer to Programmer's
+ * guide/Environment Abstraction Layer/Multiple pthread/Known Issues/rte_ring
+ * for more information.
*
*/
--
2.7.4
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] [PATCH v4] rte_ring: clarify preemptible nature of ring algorithm
2018-07-17 4:52 [dpdk-dev] [PATCH v4] rte_ring: clarify preemptible nature of ring algorithm Honnappa Nagarahalli
@ 2018-08-03 15:09 ` Olivier Matz
2018-08-05 13:40 ` Thomas Monjalon
0 siblings, 1 reply; 3+ messages in thread
From: Olivier Matz @ 2018-08-03 15:09 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: anatoly.burakov, dev, nd
On Mon, Jul 16, 2018 at 11:52:44PM -0500, Honnappa Nagarahalli wrote:
> rte_ring implementation is not preemptible only under certain
> circumstances. This clarification is helpful for data plane and
> control plane communication using rte_ring.
>
> Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Thanks!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] [PATCH v4] rte_ring: clarify preemptible nature of ring algorithm
2018-08-03 15:09 ` Olivier Matz
@ 2018-08-05 13:40 ` Thomas Monjalon
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Monjalon @ 2018-08-05 13:40 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: dev, Olivier Matz, anatoly.burakov, nd
03/08/2018 17:09, Olivier Matz:
> On Mon, Jul 16, 2018 at 11:52:44PM -0500, Honnappa Nagarahalli wrote:
> > rte_ring implementation is not preemptible only under certain
> > circumstances. This clarification is helpful for data plane and
> > control plane communication using rte_ring.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Gavin Hu <gavin.hu@arm.com>
> > Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
Applied, thanks
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-08-05 13:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-17 4:52 [dpdk-dev] [PATCH v4] rte_ring: clarify preemptible nature of ring algorithm Honnappa Nagarahalli
2018-08-03 15:09 ` Olivier Matz
2018-08-05 13:40 ` Thomas Monjalon
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).