X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fmempool_lib.rst;h=55838317b9daa8222cef65c8ef583bd18efb837c;hb=34fd4373ce76efd0236e59397c495762c2ec9e64;hp=3bb84b0a6fff808f062e9f8509f5b94b74daa47b;hpb=4ae9f32eccef0e12ec7282889fc2a2e444b8ec4d;p=dpdk.git diff --git a/doc/guides/prog_guide/mempool_lib.rst b/doc/guides/prog_guide/mempool_lib.rst index 3bb84b0a6f..55838317b9 100644 --- a/doc/guides/prog_guide/mempool_lib.rst +++ b/doc/guides/prog_guide/mempool_lib.rst @@ -17,20 +17,19 @@ This library is used by the :ref:`Mbuf Library `. Cookies ------- -In debug mode (CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG is enabled), cookies are added at the beginning and end of allocated blocks. +In debug mode, cookies are added at the beginning and end of allocated blocks. The allocated objects then contain overwrite protection fields to help debugging buffer overflows. Stats ----- -In debug mode (CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG is enabled), -statistics about get from/put in the pool are stored in the mempool structure. +In debug mode, statistics about get from/put in the pool are stored in the mempool structure. Statistics are per-lcore to avoid concurrent access to statistics counters. -Memory Alignment Constraints ----------------------------- +Memory Alignment Constraints on x86 architecture +------------------------------------------------ -Depending on hardware memory configuration, performance can be greatly improved by adding a specific padding between objects. +Depending on hardware memory configuration on X86 architecture, performance can be greatly improved by adding a specific padding between objects. The objective is to ensure that the beginning of each object starts on a different channel and rank in memory so that all channels are equally loaded. This is particularly true for packet buffers when doing L3 forwarding or flow classification. @@ -90,7 +89,7 @@ the speed at which a core can access its own cache for a specific memory pool wi The cache is composed of a small, per-core table of pointers and its length (used as a stack). This internal cache can be enabled or disabled at creation of the pool. -The maximum size of the cache is static and is defined at compilation time (CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE). +The maximum size of the cache is static and is defined at compilation time (RTE_MEMPOOL_CACHE_MAX_SIZE). :numref:`figure_mempool` shows a cache in operation. @@ -103,7 +102,9 @@ The maximum size of the cache is static and is defined at compilation time (CONF Alternatively to the internal default per-lcore local cache, an application can create and manage external caches through the ``rte_mempool_cache_create()``, ``rte_mempool_cache_free()`` and ``rte_mempool_cache_flush()`` calls. These user-owned caches can be explicitly passed to ``rte_mempool_generic_put()`` and ``rte_mempool_generic_get()``. 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 non-EAL threads too. +In contrast to the default caches, user-owned caches can be used by unregistered non-EAL threads too. + +.. _Mempool_Handlers: Mempool Handlers ------------------------ @@ -114,7 +115,7 @@ management systems and software based memory allocators, to be used with DPDK. There are two aspects to a mempool handler. * Adding the code for your new mempool operations (ops). This is achieved by - adding a new mempool ops code, and using the ``MEMPOOL_REGISTER_OPS`` macro. + adding a new mempool ops code, and using the ``RTE_MEMPOOL_REGISTER_OPS`` macro. * Using the new API to call ``rte_mempool_create_empty()`` and ``rte_mempool_set_ops_byname()`` to create a new mempool and specifying which