eal: initialize log before everything else

In order for all log messages (including CPU mismatch) to come out
through the logging library, it must be initialized as early
in rte_eal_init() as possib

eal: initialize log before everything else

In order for all log messages (including CPU mismatch) to come out
through the logging library, it must be initialized as early
in rte_eal_init() as possible on all platforms.

Where it was done before was likely historical, based on the support
of non-OS isolated CPU's which required a shared memory buffer.
That support was dropped before DPDK was publicly released.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

log: rework syslog handling

Refactor how syslog is handled, make it common to Linux and FreeBSD
The syslog facility property is better handled in lib/log
rather than in eal.
This also adds syslog su

log: rework syslog handling

Refactor how syslog is handled, make it common to Linux and FreeBSD
The syslog facility property is better handled in lib/log
rather than in eal.
This also adds syslog support to FreeBSD.

Log to syslog only if option is specified.
If no --syslog is given then use only standard error.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

eal: do not log init failure twice

The message already goes through logging, and does not need
to be printed on stderr.
Message level should be ALERT to match function name.

Signed-off-by: Stephen

eal: do not log init failure twice

The message already goes through logging, and does not need
to be printed on stderr.
Message level should be ALERT to match function name.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

eal: introduce log options parser

Rename existing log level option parser and add a little helper tracking
all options related to logs.
This will make it easier to add more log options in the next c

eal: introduce log options parser

Rename existing log level option parser and add a little helper tracking
all options related to logs.
This will make it easier to add more log options in the next commits.

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

show more ...

eal: factorize parser for log level

The code to parse for log-level option should be same on all OS variants.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Tyler Retzlaff

eal: factorize parser for log level

The code to parse for log-level option should be same on all OS variants.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...

eal: add static per-lcore memory allocation facility

Introduce DPDK per-lcore id variables, or lcore variables for short.

An lcore variable has one value for every current and future lcore
id-equip

eal: add static per-lcore memory allocation facility

Introduce DPDK per-lcore id variables, or lcore variables for short.

An lcore variable has one value for every current and future lcore
id-equipped thread.

The primary <rte_lcore_var.h> use case is for statically allocating
small, frequently-accessed data structures, for which one instance
should exist for each lcore.

Lcore variables are similar to thread-local storage (TLS, e.g., C11
_Thread_local), but decoupling the values' life time with that of the
threads.

Lcore variables are also similar in terms of functionality provided by
FreeBSD kernel's DPCPU_*() family of macros and the associated
build-time machinery. DPCPU uses linker scripts, which effectively
prevents the reuse of its, otherwise seemingly viable, approach.

The currently-prevailing way to solve the same problem as lcore
variables is to keep a module's per-lcore data as RTE_MAX_LCORE-sized
array of cache-aligned, RTE_CACHE_GUARDed structs. The benefit of
lcore variables over this approach is that data related to the same
lcore now is close (spatially, in memory), rather than data used by
the same module, which in turn avoid excessive use of padding,
polluting caches with unused data.

Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

eal/linux: fix VFIO hotplug with multiprocess

At the moment, if VFIO is not available at DPDK init, it won't be
available unless a subsequent rte_vfio_enable() is done.

Yet, even if rte_vfio_enable

eal/linux: fix VFIO hotplug with multiprocess

At the moment, if VFIO is not available at DPDK init, it won't be
available unless a subsequent rte_vfio_enable() is done.

Yet, even if rte_vfio_enable() is called again in primary and secondary
processes, a secondary process will never get to know that VFIO has been
enabled in the primary process as the MP requests handler is only
registered in EAL init.

On the other hand, moving the MP requests handler registration earlier
in EAL init is ok, as secondary process are supposed to be waiting on
eal_mcfg_wait_complete() until the primary process calls
eal_mcfg_complete().

Move vfio_mp_sync_setup() in rte_vfio_enable().

Besides, rte_eal_vfio_setup() is useless and its name with a rte_ prefix
is ambiguous as it gives the impression it is an exported/public symbol.
Remove it and directly call rte_vfio_enable() where needed.

Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>

show more ...

eal: verify MMU type for PPC64

IBM POWER systems support more than one type of memory management unit
(MMU).
The Power ISA 3.0 specification, which applies to P9 and later CPUs,
defined a new Radix

eal: verify MMU type for PPC64

IBM POWER systems support more than one type of memory management unit
(MMU).
The Power ISA 3.0 specification, which applies to P9 and later CPUs,
defined a new Radix MMU which, among other things, allows an anonymous
memory page mapping to be converted into a hugepage mapping at a specific
address.
This is a required feature in DPDK so we need to test the MMU type when
POWER systems are used and provide a more useful error message for the
user when running on an unsupported system such as P8/P9 on PowerVM.

All architectures other than ppc64le unconditionally report that the
MMU is supported.
When running with ppc64le on Linux, the MMU is tested and the actual
result is returned, while running with ppc64le on FreeBSD unconditionally
reports that the MMU is supported to avoid unnecessary breakage until
an actual test can be implemented for that environment
(i.e. keeps existing behavior without the patch).

Bugzilla ID: 1221

Suggested-by: Thomas Monjalon <thomas@monjalon.net>
Signed-off-by: David Christensen <drc@linux.ibm.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>

show more ...

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 ...

eal: use stdatomic API

Replace the use of gcc builtin __atomic_xxx intrinsics with corresponding
rte_atomic_xxx optional stdatomic API

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
A

eal: use stdatomic API

Replace the use of gcc builtin __atomic_xxx intrinsics with corresponding
rte_atomic_xxx optional stdatomic API

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: David Marchand <david.marchand@redhat.com>

show more ...

eal: rename thread name length definition

RTE_MAX_THREAD_NAME_LEN is including the NUL character,
so it should be named "size" instead of "length".
A new constant RTE_THREAD_NAME_SIZE is introduced

eal: rename thread name length definition

RTE_MAX_THREAD_NAME_LEN is including the NUL character,
so it should be named "size" instead of "length".
A new constant RTE_THREAD_NAME_SIZE is introduced for naming accuracy.
For API compatibility, the old name is kept.

At the same time, the original definition is moved
from rte_eal.h to rte_thread.h.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>

show more ...

set namespace prefix to threads

When looking at threads in a system, it can be confusing
to find some unknown threads without a clue it is started by DPDK.

Let's start all thread names with "dpdk-"

set namespace prefix to threads

When looking at threads in a system, it can be confusing
to find some unknown threads without a clue it is started by DPDK.

Let's start all thread names with "dpdk-"
plus the driver name if it comes from a driver.

One more constraint: the thread names are generally limited
to 16 characters, including the NUL character.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

show more ...

telemetry: use standard logging

Now that logging is moved out of EAL, we don't need injection of the
logtype and logging function from EAL to telemetry library, simplifying
things.

Signed-off-by: B

telemetry: use standard logging

Now that logging is moved out of EAL, we don't need injection of the
logtype and logging function from EAL to telemetry library, simplifying
things.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

show more ...

log: separate logging functions out of EAL

Move the logging capability to a separate library, free from EAL. Rename
files as appropriate, and use meson.build to select the correct file to
be built f

log: separate logging functions out of EAL

Move the logging capability to a separate library, free from EAL. Rename
files as appropriate, and use meson.build to select the correct file to
be built for each operating system, rather than having a subdir per-os.
Add new documentation section in programmers guide to cover logging in
more detail.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

show more ...

remove KNI

The KNI driver had design flaws such as calling userspace with kernel
mutex held that made it prone to deadlock. The design also introduced
security risks because the kernel driver truste

remove KNI

The KNI driver had design flaws such as calling userspace with kernel
mutex held that made it prone to deadlock. The design also introduced
security risks because the kernel driver trusted the userspace
(DPDK) kni interface. The kernel driver was never reviewed by
the upstream kernel community and would never have been accepted.

And since the Linux kernel API is not stable, it was a continual
source of maintenance issues especially with distribution kernels.

There are better ways to inject packets into the kernel such as
virtio_user, tap and XDP drivers. All of these do not need out of
tree kernel drivers.

The deprecation was announced in 22.11 release (see links for the
the techboard discussions); and users were directed to alternatives
there.

Link: https://mails.dpdk.org/archives/dev/2021-January/197077.html
Link: https://mails.dpdk.org/archives/dev/2022-June/243596.html

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

eal: use macros for help option

The macros OPT_HELP and OPT_HELP_NUM were not used where appropriate.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Bruce Richardson <bruce.richards

eal: use macros for help option

The macros OPT_HELP and OPT_HELP_NUM were not used where appropriate.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

eal: choose IOVA mode according to compilation option

The DPDK can be compiled to be run in IOVA VA mode with
'enable_iova_as_pa=false' Meson option. If there is no
explicit EAL --iova-mode paramete

eal: choose IOVA mode according to compilation option

The DPDK can be compiled to be run in IOVA VA mode with
'enable_iova_as_pa=false' Meson option. If there is no
explicit EAL --iova-mode parameter specified in the command
line the rte_eal_init() tried to deduce VA or PA mode without
taking into account the above mentioned compile time option,
resulting into initialization failure.

Also, for FreeBSD and Windows EALs the IOVA mode checks were
added or moved to be after the mode selection code block for
final checking.

Fixes: a986c2b7973d ("build: add option to configure IOVA mode as PA")
Cc: stable@dpdk.org

Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Reviewed-by: Morten Brørup <mb@smartsharesystems.com>

show more ...

eal/linux: fix secondary process crash for mp hotplug requests

Secondary would crash if it tries to handle mp requests before memory
init, since globals such as eth_dev_shared_data_lock are not acce

eal/linux: fix secondary process crash for mp hotplug requests

Secondary would crash if it tries to handle mp requests before memory
init, since globals such as eth_dev_shared_data_lock are not accessible
to it at this moment.

Fixes: 244d5130719c ("eal: enable hotplug on multi-process")
Cc: stable@dpdk.org

Signed-off-by: Zhihong Wang <wangzhihong.wzh@bytedance.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>

show more ...

eal: avoid calling cleanup twice

If an app calls rte_eal_cleanup() inside it's own code, then cleanup
could be called a second time automatically when the app exits. While
mostly harmless, we can av

eal: avoid calling cleanup twice

If an app calls rte_eal_cleanup() inside it's own code, then cleanup
could be called a second time automatically when the app exits. While
mostly harmless, we can avoid any potential issues by guaranteeing that
cleanup only gets called once, in the same way that eal_init only ever
gets called once.

Note: This patch only touches Linux and FreeBSD. Windows EAL does not
have run-once guard on the init function, so omitting it in the cleanup
function.

Fixes: aec9c13c5257 ("eal: add function to release internal resources")
Cc: stable@dpdk.org

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

show more ...

mem: rework malloc heap init

rte_eal_memory_init() and rte_eal_malloc_heap_init() must be called in
a common section taking rte_mcfg_mem_read_lock().
Split rte_eal_malloc_heap_init() in two so that

mem: rework malloc heap init

rte_eal_memory_init() and rte_eal_malloc_heap_init() must be called in
a common section taking rte_mcfg_mem_read_lock().
Split rte_eal_malloc_heap_init() in two so that the mem lock is taken
in rte_eal_init() making lock checks trivial (once annotated in the next
patch).

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

show more ...

build: clarify configuration without IOVA field in mbuf

The impact of the option "enable_iova_as_pa" is explained for users.

Also the code flag "RTE_IOVA_AS_PA" is renamed as "RTE_IOVA_IN_MBUF"
in

build: clarify configuration without IOVA field in mbuf

The impact of the option "enable_iova_as_pa" is explained for users.

Also the code flag "RTE_IOVA_AS_PA" is renamed as "RTE_IOVA_IN_MBUF"
in order to be more accurate (IOVA mode is decided at runtime),
and more readable in the code.

Similarly the drivers are using the variable "require_iova_in_mbuf"
instead of "pmd_supports_disable_iova_as_pa" with an opposite meaning.
By default, it is assumed that drivers require the IOVA field in mbuf.
The drivers which support removing this field have to declare themselves.
Some bus drivers are declared compatible.

If the option "enable_iova_as_pa" is disabled, the unsupported drivers
will be listed with the new reason text "requires IOVA in mbuf".

Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>

show more ...

eal/linux: use program short name from libc

Glibc already has a documented variable with the program
name so use it instead of computing the value.

Signed-off-by: Stephen Hemminger <stephen@network

eal/linux: use program short name from libc

Glibc already has a documented variable with the program
name so use it instead of computing the value.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

eal: cleanup alarm and hotplug before memory detach

Alarm and multiprocess hotplug still need access hugepage memory,
if alarm event processed after memory detach, it may cause SEGV.
So cleanup alar

eal: cleanup alarm and hotplug before memory detach

Alarm and multiprocess hotplug still need access hugepage memory,
if alarm event processed after memory detach, it may cause SEGV.
So cleanup alarm and multiprocess hotplug before memory detach.

Fixes: 90b13ab8d4f7 ("alarm: remove direct access to interrupt handle")
Fixes: a0cc7be20dd1 ("mem: cleanup multiprocess resources")
Cc: stable@dpdk.org

Signed-off-by: Fengnan Chang <changfengnan@bytedance.com>

show more ...

eal: add platform agnostic thread set name API

Add a rte_thread_set_name that sets the name of an rte_thread_t thread.
This is a replacement for the rte_thread_setname(pthread_t, ...) which
exposes

eal: add platform agnostic thread set name API

Add a rte_thread_set_name that sets the name of an rte_thread_t thread.
This is a replacement for the rte_thread_setname(pthread_t, ...) which
exposes platform-specific details.

Introduces Windows implementation for rte_thread_set_name not previously
available on Windows.

Adapt drivers/mlx5 to use the new internal rte_thread_set_name API
instead of the soon to be deprecated rte_thread_setname API.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...

eal: stop using pthread for lcores and control threads

Replace the use of pthread_t in struct lcore_config with the EAL
rte_thread_t type.

Replace the direct use of pthread_create(), pthread_self()

eal: stop using pthread for lcores and control threads

Replace the use of pthread_t in struct lcore_config with the EAL
rte_thread_t type.

Replace the direct use of pthread_create(), pthread_self()
pthread_getaffinity_np() and pthread_setaffinity_np().

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: David Marchand <david.marchand@redhat.com>

show more ...