lib: add more logging helpers

Add helpers for logging messages in libraries instead of calling
RTE_LOG() directly.
Those helpers take care of adding a \n: this will make the transition to
RTE_LOG_LI

lib: add more logging helpers

Add helpers for logging messages in libraries instead of calling
RTE_LOG() directly.
Those helpers take care of adding a \n: this will make the transition to
RTE_LOG_LINE trivial.

Note:
- for acl and sched libraries that still has some debug multilines
messages, a direct call to RTE_LOG is used: this will make it easier to
notice such special cases,

Signed-off-by: David Marchand <david.marchand@redhat.com>

show more ...

mem: fix deadlock with multiprocess

The issue arose due to changes in the DPDK read-write lock
implementation. Following these changes, the RW-lock no longer supports
recursion, implying that a sing

mem: fix deadlock with multiprocess

The issue arose due to changes in the DPDK read-write lock
implementation. Following these changes, the RW-lock no longer supports
recursion, implying that a single thread shouldn't obtain a read lock if
it already possesses one. The problem arises during initialization: the
rte_eal_init() function acquires the memory_hotplug_lock, and later on,
there are sequences of calls that acquire it again without releasing it.
* rte_eal_memory_init() -> eal_memalloc_init() -> rte_memseg_list_walk()
* rte_eal_memory_init() -> rte_eal_hugepage_init() ->
eal_dynmem_hugepage_init() -> rte_memseg_list_walk()
This scenario introduces the risk of a potential deadlock when concurrent
write locks are applied to the same memory_hotplug_lock. To address this
locally, we resolved the issue by replacing rte_memseg_list_walk() with
rte_memseg_list_walk_thread_unsafe().

Bugzilla ID: 1277
Fixes: 832cecc03d77 ("rwlock: prevent readers from starving writers")
Cc: stable@dpdk.org

Signed-off-by: Artemy Kovalyov <artemyko@nvidia.com>
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Tested-by: Jonathan Erb <jonathan.erb@threatblockr.com>

show more ...

mem: fix memsegs exhausted message

When there is not enough space to memsegs, we should prompt
which configuration should be modified instead of printing
some numbers.

Fixes: dd61b34d580b ("mem: er

mem: fix memsegs exhausted message

When there is not enough space to memsegs, we should prompt
which configuration should be modified instead of printing
some numbers.

Fixes: dd61b34d580b ("mem: error if requesting more segments than MAX_MEMSEG")
Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")
Cc: stable@dpdk.org

Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

eal: remove unneeded includes from a public header

Do not include <ctype.h>, <errno.h>, and <stdlib.h> from <rte_common.h>,
because they are not used by this file.
Include the needed headers directl

eal: remove unneeded includes from a public header

Do not include <ctype.h>, <errno.h>, and <stdlib.h> from <rte_common.h>,
because they are not used by this file.
Include the needed headers directly from the files that need them.

Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...

mem: check allocation in dynamic hugepage init

The function malloc() could return NULL, the return value
need to be checked.

Fixes: 6f63858e55e6 ("mem: prevent preallocated pages from being freed")

mem: check allocation in dynamic hugepage init

The function malloc() could return NULL, the return value
need to be checked.

Fixes: 6f63858e55e6 ("mem: prevent preallocated pages from being freed")
Cc: stable@dpdk.org

Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>

show more ...

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 <bruce.richardson@intel.com>

show more ...