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

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

Dealing with C++ should delegate to the individual include file level,
rather than being imposed by the user of that file. For example,
forcing C linkage prevents __Generic macros being replaced with
overloaded static inline functions in C++ translation units.

Eliminate 'extern "C"' from files which do not declare any symbols
(e.g., only macros or struct types).

On the other hand, the headers check is too naive in assuming that all
headers must contain a 'extern "C"'. Such a check was added in commit
1ee492bdc4ff ("buildtools/chkincs: check missing C++ guards").
Since this current change results in many headers not containing such
a token, remove the check for 'extern "C"' until we have a better
implementation.

Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>

show more ...

timer: override CPU TSC frequency with OS value

The CPU provided value is often not accurate, allow overriding it
based on info from the host OS.

On Linux x86, if the tsc_known_freq cpu flag is mis

timer: override CPU TSC frequency with OS value

The CPU provided value is often not accurate, allow overriding it
based on info from the host OS.

On Linux x86, if the tsc_known_freq cpu flag is missing, it means
the kernel doesn't trust it and calculates its own. We should do
the same to avoid drift.

On Freebsd, we have access to the kernel tsc_hz value, just use it.

Bugzilla ID: 959

Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

timer: improve TSC estimation accuracy

In practice, the frequency is often not a nice round number, while
the estimation results are rather accurate, just a couple of KHz
away from the kernel's tsc_

timer: improve TSC estimation accuracy

In practice, the frequency is often not a nice round number, while
the estimation results are rather accurate, just a couple of KHz
away from the kernel's tsc_khz value, so it should suffice.

Rounding to 10MHz can cause a significant drift from real time,
up to a second per 10 minutes.

Bugzilla ID: 959

Signed-off-by: Isaac Boukris <iboukris@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

alarm: fix alarm cancel

Two threads:
- A, executing rte_eal_alarm_cancel,
- B, executing eal_alarm_callback.

Such case can cause starvation of thread B.
Please see that there is a small time window

alarm: fix alarm cancel

Two threads:
- A, executing rte_eal_alarm_cancel,
- B, executing eal_alarm_callback.

Such case can cause starvation of thread B.
Please see that there is a small time window between lock and unlock in
thread A, so thread B must be switched to within a very small time window,
so that it can obtain the lock.

Solution to this problem is use sched_yield(), which puts current thread
(A) at the end of thread execution priority queue and allows thread B to
execute.

The issue can be observed e.g. on hot-pluggable device detach path.
On such path, rte_alarm can used to check if DPDK has completed the
detachment.
Waiting for completion, rte_eal_alarm_cancel is called, while another
thread periodically calls eal_alarm_callback causing the issue to occur.

Signed-off-by: Wojciech Panfil <wojciech.panfil@intel.com>
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>

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

eal/linux: lower log level on allocation attempt failure

On a ARM system with only 2MB hugepages configured, EAL emits an error
log with allocations larger than 512MB.

Example with testpmd:
$ dpdk-

eal/linux: lower log level on allocation attempt failure

On a ARM system with only 2MB hugepages configured, EAL emits an error
log with allocations larger than 512MB.

Example with testpmd:
$ dpdk-testpmd --in-memory --no-pci --log-level=*:debug -- -i
...
EAL: In-memory mode enabled, hugepages of size 33554432 bytes will be
allocated anonymously
EAL: No free 32768 kB hugepages reported on node 0
EAL: In-memory mode enabled, hugepages of size 65536 bytes will be
allocated anonymously
EAL: No free 64 kB hugepages reported on node 0
EAL: In-memory mode enabled, hugepages of size 1073741824 bytes will be
allocated anonymously
EAL: No free 1048576 kB hugepages reported on node 0
...
EAL: Detected memory type: socket_id:0 hugepage_sz:1073741824
EAL: Detected memory type: socket_id:0 hugepage_sz:33554432
EAL: Detected memory type: socket_id:0 hugepage_sz:2097152
EAL: Detected memory type: socket_id:0 hugepage_sz:65536
EAL: Creating 2 segment lists: n_segs:32 socket_id:0
hugepage_sz:1073741824
...
EAL: Creating 2 segment lists: n_segs:1024 socket_id:0
hugepage_sz:33554432
...
EAL: Creating 4 segment lists: n_segs:8192 socket_id:0
hugepage_sz:2097152
...
EAL: Creating 4 segment lists: n_segs:8192 socket_id:0
hugepage_sz:65536
...
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: alloc_seg(): mmap() failed: Cannot allocate memory
EAL: Ask a virtual area of 0x40000000 bytes
EAL: Virtual area found at 0x140000000 (size = 0x40000000)
EAL: attempted to allocate 2 segments, but only 0 were allocated
EAL: Restoring previous memory policy: 4
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: eal_memalloc_alloc_seg_bulk(): couldn't find suitable memseg_list
EAL: Restoring previous memory policy: 4
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 4
EAL: request: mp_malloc_sync
EAL: No shared files mode enabled, IPC is disabled
EAL: Heap on socket 0 was expanded by 1064MB
...

The reason is that the memzone allocation (~1GB large) would require
17017 (32kB) segments. However, as displayed in the early logs, a 32kB
memory segment list can only host 8192 segments (controlled by the build
option RTE_MAX_MEMSEG_PER_LIST).

This log message is misleading as there is no issue in the end: the
allocation succeeded with 2MB hugepages.

Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime")
Cc: stable@dpdk.org

Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

eal/linux: hide some local signal handler code

Only used in one file, and not an exported symbol should be static.

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