History log of /dpdk/lib/eal/include/rte_memory.h (Results 1 – 5 of 5)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v22.03, v22.03-rc4, v22.03-rc3, v22.03-rc2, v22.03-rc1
# 2edd037c 03-Feb-2022 Dmitry Kozlyuk <[email protected]>

mem: add dirty malloc element support

EAL malloc layer assumed all free elements content
is filled with zeros ("clean"), as opposed to uninitialized ("dirty").
This assumption was ensured in two way

mem: add dirty malloc element support

EAL malloc layer assumed all free elements content
is filled with zeros ("clean"), as opposed to uninitialized ("dirty").
This assumption was ensured in two ways:
1. EAL memalloc layer always returned clean memory.
2. Freed memory was cleared before returning into the heap.

Clearing the memory can be as slow as around 14 GiB/s.
To save doing so, memalloc layer is allowed to return dirty memory.
Such segments being marked with RTE_MEMSEG_FLAG_DIRTY.
The allocator tracks elements that contain dirty memory
using the new flag in the element header.
When clean memory is requested via rte_zmalloc*()
and the suitable element is dirty, it is cleared on allocation.
When memory is deallocated, the freed element is joined
with adjacent free elements, and the dirty flag is updated:

a) If the joint element contains dirty parts, it is dirty:

dirty + freed + dirty = dirty => no need to clean
freed + dirty = dirty the freed memory

Dirty parts may be large (e.g. initial allocation),
so clearing them could create unpredictable slowdown.

b) If the only dirty part of the joint element
is the freed memory, the joint element can be made clean:

clean + freed + clean = clean => freed memory
clean + freed = clean must be cleared
freed + clean = clean
freed = clean

This logic naturally reproduces the old behavior
and always applies in modes when EAL memalloc layer
returns only clean segments.

As a result, memory is either cleared on free, as before,
or it will be cleared on allocation if need be, but never twice.

Signed-off-by: Dmitry Kozlyuk <[email protected]>
Reviewed-by: Anatoly Burakov <[email protected]>

show more ...


Revision tags: v21.11, v21.11-rc4, v21.11-rc3, v21.11-rc2, v21.11-rc1
# 27e7e250 10-Sep-2021 Anatoly Burakov <[email protected]>

mem: promote DMA mask API to stable

As per ABI policy, move the formerly experimental API's to the stable
section.

Signed-off-by: Anatoly Burakov <[email protected]>
Acked-by: Ray Kinsella

mem: promote DMA mask API to stable

As per ABI policy, move the formerly experimental API's to the stable
section.

Signed-off-by: Anatoly Burakov <[email protected]>
Acked-by: Ray Kinsella <[email protected]>

show more ...


# acddc33b 10-Sep-2021 Anatoly Burakov <[email protected]>

mem: promote external memory API to stable

As per ABI policy, move the formerly experimental API's to the stable
section.

Signed-off-by: Anatoly Burakov <[email protected]>
Acked-by: Ray Ki

mem: promote external memory API to stable

As per ABI policy, move the formerly experimental API's to the stable
section.

Signed-off-by: Anatoly Burakov <[email protected]>
Acked-by: Ray Kinsella <[email protected]>

show more ...


# b8937750 10-Sep-2021 Anatoly Burakov <[email protected]>

mem: promote memseg API to stable

As per ABI policy, move the formerly experimental API's to the stable
section.

Signed-off-by: Anatoly Burakov <[email protected]>
Acked-by: Ray Kinsella <m

mem: promote memseg API to stable

As per ABI policy, move the formerly experimental API's to the stable
section.

Signed-off-by: Anatoly Burakov <[email protected]>
Acked-by: Ray Kinsella <[email protected]>

show more ...


Revision tags: 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 ...