xref: /f-stack/dpdk/doc/guides/mempool/stack.rst (revision 2d9fd380)
1*2d9fd380Sjfb8856606..  SPDX-License-Identifier: BSD-3-Clause
2*2d9fd380Sjfb8856606    Copyright(c) 2020 Intel Corporation.
3*2d9fd380Sjfb8856606
4*2d9fd380Sjfb8856606Stack Mempool Driver
5*2d9fd380Sjfb8856606====================
6*2d9fd380Sjfb8856606
7*2d9fd380Sjfb8856606**rte_mempool_stack** is a pure software mempool driver based on the
8*2d9fd380Sjfb8856606``rte_stack`` DPDK library. For run-to-completion workloads with sufficiently
9*2d9fd380Sjfb8856606large per-lcore caches, the mbufs will likely stay in the per-lcore caches and
10*2d9fd380Sjfb8856606the mempool type (ring, stack, etc.) will have a negligible impact on
11*2d9fd380Sjfb8856606performance. However a stack-based mempool is often better suited to pipelined
12*2d9fd380Sjfb8856606packet-processing workloads (which allocate and free mbufs on different lcores)
13*2d9fd380Sjfb8856606than a ring-based mempool, since its LIFO behavior results in better temporal
14*2d9fd380Sjfb8856606locality and a minimal memory footprint even if the mempool is
15*2d9fd380Sjfb8856606over-provisioned. Users are encouraged to benchmark with multiple mempool types
16*2d9fd380Sjfb8856606to determine which works best for their specific application.
17*2d9fd380Sjfb8856606
18*2d9fd380Sjfb8856606The following modes of operation are available for the stack mempool driver and
19*2d9fd380Sjfb8856606can be selected as described in :ref:`Mempool_Handlers`:
20*2d9fd380Sjfb8856606
21*2d9fd380Sjfb8856606- ``stack``
22*2d9fd380Sjfb8856606
23*2d9fd380Sjfb8856606  The underlying **rte_stack** operates in standard (lock-based) mode.
24*2d9fd380Sjfb8856606  For more information please refer to :ref:`Stack_Library_Std_Stack`.
25*2d9fd380Sjfb8856606
26*2d9fd380Sjfb8856606- ``lf_stack``
27*2d9fd380Sjfb8856606
28*2d9fd380Sjfb8856606  The underlying **rte_stack** operates in lock-free mode. For more
29*2d9fd380Sjfb8856606  information please refer to :ref:`Stack_Library_LF_Stack`.
30*2d9fd380Sjfb8856606
31*2d9fd380Sjfb8856606The standard stack outperforms the lock-free stack on average, however the
32*2d9fd380Sjfb8856606standard stack is non-preemptive: if a mempool user is preempted while holding
33*2d9fd380Sjfb8856606the stack lock, that thread will block all other mempool accesses until it
34*2d9fd380Sjfb8856606returns and releases the lock. As a result, an application using the standard
35*2d9fd380Sjfb8856606stack whose threads can be preempted can suffer from brief, infrequent
36*2d9fd380Sjfb8856606performance hiccups.
37*2d9fd380Sjfb8856606
38*2d9fd380Sjfb8856606The lock-free stack, by design, is not susceptible to this problem; one thread can
39*2d9fd380Sjfb8856606be preempted at any point during a push or pop operation and will not impede
40*2d9fd380Sjfb8856606the progress of any other thread.
41*2d9fd380Sjfb8856606
42*2d9fd380Sjfb8856606For a more detailed description of the stack implementations, please refer to
43*2d9fd380Sjfb8856606:doc:`../prog_guide/stack_lib`.
44