|
Revision tags: v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2 |
|
| #
30a1de10 |
| 15-Feb-2022 |
Sean Morrissey <[email protected]> |
lib: remove unneeded header includes
These header includes have been flagged by the iwyu_tool and removed.
Signed-off-by: Sean Morrissey <[email protected]>
|
|
Revision tags: v22.03-rc1 |
|
| #
32b4771c |
| 03-Feb-2022 |
Dmitry Kozlyuk <[email protected]> |
eal/linux: allow hugepage file reuse
Linux EAL ensured that mapped hugepages are clean by always mapping from newly created files: existing hugepage backing files were always removed. In this case,
eal/linux: allow hugepage file reuse
Linux EAL ensured that mapped hugepages are clean by always mapping from newly created files: existing hugepage backing files were always removed. In this case, the kernel clears the page to prevent data leaks, because the mapped memory may contain leftover data from the previous process that was using this memory. Clearing takes the bulk of the time spent in mmap(2), increasing EAL initialization time.
Introduce a mode to keep existing files and reuse them in order to speed up initial memory allocation in EAL. Hugepages mapped from such files may contain data left by the previous process that used this memory, so RTE_MEMSEG_FLAG_DIRTY is set for their segments. If multiple hugepages are mapped from the same file: 1. When fallocate(2) is used, all memory mapped from this file is considered dirty, because it is unknown which parts of the file are holes. 2. When ftruncate(3) is used, memory mapped from this file is considered dirty unless the file is extended to create a new mapping, which implies clean memory.
Signed-off-by: Dmitry Kozlyuk <[email protected]> Reviewed-by: Anatoly Burakov <[email protected]>
show more ...
|
| #
52d7d91e |
| 03-Feb-2022 |
Dmitry Kozlyuk <[email protected]> |
eal: refactor --huge-unlink storage
In preparation to extend --huge-unlink option semantics refactor how it is stored in the internal configuration. It makes future changes more isolated.
Signed-of
eal: refactor --huge-unlink storage
In preparation to extend --huge-unlink option semantics refactor how it is stored in the internal configuration. It makes future changes more isolated.
Signed-off-by: Dmitry Kozlyuk <[email protected]> Acked-by: Thomas Monjalon <[email protected]> Acked-by: Anatoly Burakov <[email protected]>
show more ...
|
| #
8a5a9140 |
| 23-Dec-2021 |
Stephen Hemminger <[email protected]> |
eal/linux: log hugepage create errors with filename
While debugging running DPDK service in a container, it is useful to see which file creation failed. Don't hide this failure with DEBUG.
Cc: sta
eal/linux: log hugepage create errors with filename
While debugging running DPDK service in a container, it is useful to see which file creation failed. Don't hide this failure with DEBUG.
Cc: [email protected]
Signed-off-by: Stephen Hemminger <[email protected]> Acked-by: Bruce Richardson <[email protected]>
show more ...
|
|
Revision tags: v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2 |
|
| #
9bffc928 |
| 29-Oct-2021 |
Olivier Matz <[email protected]> |
mem: fix dynamic hugepage mapping in container
Since its introduction in 2018, the SIGBUS handler was never registered, and all related functions were unused.
A SIGBUS can be received by the applic
mem: fix dynamic hugepage mapping in container
Since its introduction in 2018, the SIGBUS handler was never registered, and all related functions were unused.
A SIGBUS can be received by the application when accessing to hugepages even if mmap() was successful, This happens especially when running inside containers when there is not enough hugepages. In this case, we need to recover. A similar scheme can be found in eal_memory.c.
Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime") Cc: [email protected]
Signed-off-by: Olivier Matz <[email protected]> Reviewed-by: Maxime Coquelin <[email protected]> Acked-by: David Marchand <[email protected]>
show more ...
|
|
Revision tags: v21.11-rc1, v21.08, v21.08-rc4, v21.08-rc3, v21.08-rc2, v21.08-rc1, v21.05, v21.05-rc4, v21.05-rc3, v21.05-rc2, v21.05-rc1 |
|
| #
99a2dd95 |
| 20-Apr-2021 |
Bruce Richardson <[email protected]> |
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also m
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also makes it awkward to add features referring to individual libraries in the build - should the lib names be specified with or without the prefix. Therefore, we can just remove the library prefix and use the library's unique name as the directory name, i.e. 'eal' rather than 'librte_eal'
Signed-off-by: Bruce Richardson <[email protected]>
show more ...
|