The Environment Abstraction Layer (EAL) is responsible for gaining access to low-level resources such as hardware and memory space.
It provides a generic interface that hides the environment specifics from the applications and libraries.
It is the responsibility of the initialization routine to decide how to allocate these resources
-(that is, memory space, PCI devices, timers, consoles, and so on).
+(that is, memory space, devices, timers, consoles, and so on).
Typical services expected from the EAL are:
* System Memory Reservation:
The EAL facilitates the reservation of different memory zones, for example, physical memory areas for device interactions.
-* PCI Address Abstraction: The EAL provides an interface to access PCI address space.
-
* Trace and Debug Functions: Logs, dump_stack, panic and so on.
* Utility Functions: Spinlocks and atomic counters that are not provided in libc.
---------------------------------------------
In a Linux user space environment, the DPDK application runs as a user-space application using the pthread library.
-PCI information about devices and address space is discovered through the /sys kernel interface and through kernel modules such as uio_pci_generic, or igb_uio.
-Refer to the UIO: User-space drivers documentation in the Linux kernel. This memory is mmap'd in the application.
The EAL performs physical memory allocation using mmap() in hugetlbfs (using huge page sizes to increase performance).
This memory is exposed to DPDK service layers such as the :ref:`Mempool Library <Mempool_Library>`.
to deny them), allocation validator callbacks are also available via
``rte_mem_alloc_validator_callback_register()`` function.
+A default validator callback is provided by EAL, which can be enabled with a
+``--socket-limit`` command-line option, for a simple way to limit maximum amount
+of memory that can be used by DPDK application.
+
.. note::
In multiprocess scenario, all related processes (i.e. primary process, and
If neither ``-m`` nor ``--socket-mem`` were specified, the entire available
hugepage memory will be preallocated.
++ Hugepage allocation matching
+
+This behavior is enabled by specifying the ``--match-allocations`` command-line
+switch to the EAL. This switch is Linux-only and not supported with
+``--legacy-mem`` nor ``--no-huge``.
+
+Some applications using memory event callbacks may require that hugepages be
+freed exactly as they were allocated. These applications may also require
+that any allocation from the malloc heap not span across allocations
+associated with two different memory event callbacks. Hugepage allocation
+matching can be used by these types of applications to satisfy both of these
+requirements. This can result in some increased memory usage which is
+very dependent on the memory allocation patterns of the application.
+
+ 32-bit support
Additional restrictions are present when running in 32-bit mode. In dynamic
can later be mapped into that preallocated VA space (if dynamic memory mode
is enabled), and can optionally be mapped into it at startup.
-PCI Access
-~~~~~~~~~~
-
-The EAL uses the /sys/bus/pci utilities provided by the kernel to scan the content on the PCI bus.
-To access PCI memory, a kernel module called uio_pci_generic provides a /dev/uioX device file
-and resource files in /sys
-that can be mmap'd to obtain access to PCI address space from the application.
-The DPDK-specific igb_uio module can also be used for this. Both drivers use the uio kernel feature (userland driver).
+Support for Externally Allocated Memory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It is possible to use externally allocated memory in DPDK, using a set of malloc
+heap API's. Support for externally allocated memory is implemented through
+overloading the socket ID - externally allocated heaps will have socket ID's
+that would be considered invalid under normal circumstances. Requesting an
+allocation to take place from a specified externally allocated memory is a
+matter of supplying the correct socket ID to DPDK allocator, either directly
+(e.g. through a call to ``rte_malloc``) or indirectly (through data
+structure-specific allocation API's such as ``rte_ring_create``).
+
+Since there is no way DPDK can verify whether memory are is available or valid,
+this responsibility falls on the shoulders of the user. All multiprocess
+synchronization is also user's responsibility, as well as ensuring that all
+calls to add/attach/detach/remove memory are done in the correct order. It is
+not required to attach to a memory area in all processes - only attach to memory
+areas as needed.
+
+The expected workflow is as follows:
+
+* Get a pointer to memory area
+* Create a named heap
+* Add memory area(s) to the heap
+ - If IOVA table is not specified, IOVA addresses will be assumed to be
+ unavailable, and DMA mappings will not be performed
+ - Other processes must attach to the memory area before they can use it
+* Get socket ID used for the heap
+* Use normal DPDK allocation procedures, using supplied socket ID
+* If memory area is no longer needed, it can be removed from the heap
+ - Other processes must detach from this memory area before it can be removed
+* If heap is no longer needed, remove it
+ - Socket ID will become invalid and will not be reused
+
+For more information, please refer to ``rte_malloc`` API documentation,
+specifically the ``rte_malloc_heap_*`` family of function calls.
Per-lcore and Shared Variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Locks and atomic operations are per-architecture (i686 and x86_64).
+IOVA Mode Configuration
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Auto detection of the IOVA mode, based on probing the bus and IOMMU configuration, may not report
+the desired addressing mode when virtual devices that are not directly attached to the bus are present.
+To facilitate forcing the IOVA mode to a specific value the EAL command line option ``--iova-mode`` can
+be used to select either physical addressing('pa') or virtual addressing('va').
+
Memory Segments and Memory Zones (memzone)
------------------------------------------
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 preemptible single-producer and single-consumer use case.
+
+ 2. It CAN be used for non-preemptible multi-producer and preemptible single-consumer use case.
- 1. It CAN be used for any single-producer or single-consumer situation.
+ 3. It CAN be used for preemptible single-producer and non-preemptible multi-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.
+ 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.
- 3. It MUST not be used by multi-producer/consumer pthreads, whose scheduling policies are SCHED_FIFO or SCHED_RR.
+ 5. It MUST not be used by multi-producer/consumer pthreads, whose scheduling policies are SCHED_FIFO or SCHED_RR.
+ rte_timer
git.droids-corp.org / dpdk.git / blobdiff