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

eal/x86: fix atomic thread fence with MSVC

MSVC does not expose legacy atomics. When the legacy atomics were
excluded rte_atomic_thread_fence was also unintentionally excluded

Adjust the conditiona

eal/x86: fix atomic thread fence with MSVC

MSVC does not expose legacy atomics. When the legacy atomics were
excluded rte_atomic_thread_fence was also unintentionally excluded

Adjust the conditional compilation check to expose
rte_atomic_thread_fence.

Fixes: 27da6a123414 ("eal: hide legacy atomics API for MSVC")

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

show more ...

eal: use stdatomic API in public headers

Adapt the EAL public headers to use rte optional atomics API instead of
directly using and exposing toolchain specific atomic builtin intrinsics.

Signed-off

eal: use stdatomic API in public headers

Adapt the EAL public headers to use rte optional atomics API instead of
directly using and exposing toolchain specific atomic builtin intrinsics.

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

show more ...

eal: hide legacy atomics API for MSVC

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of t

eal: hide legacy atomics API for MSVC

It's discouraged to use rte_atomics APIs instead standard APIs should be
used from C11. Since MSVC is a new toolchain/platform combination block
visibility of the rte_atomic APIs from day 1.

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

show more ...

eal/x86: implement barriers for MSVC

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: T

eal/x86: implement barriers for MSVC

Inline assembly is not supported for MSVC x64 instead expand
rte_compiler_barrier as _ReadWriteBarrier and for rte_smp_mb
_m_mfence intrinsics.

Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Acked-by: Morten Brørup <mb@smartsharesystems.com>

show more ...

fix spelling in comments and strings

The tool comes from https://github.com/jsoref

Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

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