This comment makes users aware of the non-blocking ring option and its
caveats.

Signed-off-by: Gage Eads <gage.e...@intel.com>
---
 doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst 
b/doc/guides/prog_guide/env_abstraction_layer.rst
index 9497b879c..b6ac236d6 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -541,7 +541,7 @@ Known Issues
 
   5. It MUST not be used by multi-producer/consumer pthreads, whose scheduling 
policies are SCHED_FIFO or SCHED_RR.
 
-  Alternatively, x86_64 applications can use the non-blocking stack mempool 
handler. When considering this handler, note that:
+  Alternatively, x86_64 applications can use the non-blocking ring or stack 
mempool handlers. When considering one of them, note that:
 
   - it is limited to the x86_64 platform, because it uses an instruction 
(16-byte compare-and-swap) that is not available on other platforms.
   - it has worse average-case performance than the non-preemptive rte_ring, 
but software caching (e.g. the mempool cache) can mitigate this by reducing the 
number of handler operations.
-- 
2.13.6

Reply via email to