doc: add stack mempool guide
authorGage Eads <gage.eads@intel.com>
Wed, 7 Oct 2020 14:18:32 +0000 (09:18 -0500)
committerDavid Marchand <david.marchand@redhat.com>
Thu, 8 Oct 2020 07:34:58 +0000 (09:34 +0200)
This guide describes the two stack modes, their tradeoffs, and (via a
reference to the mempool guide) how to enable them.

Signed-off-by: Gage Eads <gage.eads@intel.com>
Reviewed-by: Olivier Matz <olivier.matz@6wind.com>
doc/guides/mempool/index.rst
doc/guides/mempool/stack.rst [new file with mode: 0644]
doc/guides/prog_guide/mempool_lib.rst
doc/guides/prog_guide/stack_lib.rst

index bbd02fd..a0e5546 100644 (file)
@@ -14,3 +14,4 @@ application through the mempool API.
     octeontx
     octeontx2
     ring
+    stack
diff --git a/doc/guides/mempool/stack.rst b/doc/guides/mempool/stack.rst
new file mode 100644 (file)
index 0000000..ab71716
--- /dev/null
@@ -0,0 +1,43 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+    Copyright(c) 2020 Intel Corporation.
+
+Stack Mempool Driver
+====================
+
+**rte_mempool_stack** is a pure software mempool driver based on the
+``rte_stack`` DPDK library. For run-to-completion workloads with sufficiently
+large per-lcore caches, the mbufs will likely stay in the per-lcore caches and
+the mempool type (ring, stack, etc.) will have a negligible impact on
+performance. However a stack-based mempool is often better suited to pipelined
+packet-processing workloads (which allocate and free mbufs on different lcores)
+than a ring-based mempool, since its LIFO behavior results in better temporal
+locality and a minimal memory footprint even if the mempool is
+over-provisioned. Users are encouraged to benchmark with multiple mempool types
+to determine which works best for their specific application.
+
+The following modes of operation are available for the stack mempool driver and
+can be selected as described in :ref:`Mempool_Handlers`:
+
+- ``stack``
+
+  The underlying **rte_stack** operates in standard (lock-based) mode.
+  For more information please refer to :ref:`Stack_Library_Std_Stack`.
+
+- ``lf_stack``
+
+  The underlying **rte_stack** operates in lock-free mode. For more
+  information please refer to :ref:`Stack_Library_LF_Stack`.
+
+The standard stack outperforms the lock-free stack on average, however the
+standard stack is non-preemptive: if a mempool user is preempted while holding
+the stack lock, that thread will block all other mempool accesses until it
+returns and releases the lock. As a result, an application using the standard
+stack whose threads can be preempted can suffer from brief, infrequent
+performance hiccups.
+
+The lock-free stack, by design, is not susceptible to this problem; one thread can
+be preempted at any point during a push or pop operation and will not impede
+the progress of any other thread.
+
+For a more detailed description of the stack implementations, please refer to
+:doc:`../prog_guide/stack_lib`.
index f0bdcd3..890535e 100644 (file)
@@ -104,6 +104,8 @@ These user-owned caches can be explicitly passed to ``rte_mempool_generic_put()`
 The ``rte_mempool_default_cache()`` call returns the default internal cache if any.
 In contrast to the default caches, user-owned caches can be used by unregistered non-EAL threads too.
 
+.. _Mempool_Handlers:
+
 Mempool Handlers
 ------------------------
 
index 8fe8804..3097cab 100644 (file)
@@ -28,6 +28,8 @@ Implementation
 The library supports two types of stacks: standard (lock-based) and lock-free.
 Both types use the same set of interfaces, but their implementations differ.
 
+.. _Stack_Library_Std_Stack:
+
 Lock-based Stack
 ----------------
 
@@ -35,6 +37,8 @@ The lock-based stack consists of a contiguous array of pointers, a current
 index, and a spinlock. Accesses to the stack are made multi-thread safe by the
 spinlock.
 
+.. _Stack_Library_LF_Stack:
+
 Lock-free Stack
 ------------------