IOVA mode in DPDK is either PA or VA.
The new build option enable_iova_as_pa configures the mode to PA
at compile time.
By default, this option is enabled.
If the option is disabled, only drivers which support it are enabled.
Supported driver can set the flag pmd_supports_disable_iova_as_pa
in its build file.
mbuf structure holds the physical (PA) and virtual address (VA).
If IOVA as PA is disabled at compile time, PA field (buf_iova)
of mbuf is redundant as it is the same as VA
and is replaced by a dummy field.
Signed-off-by: Shijith Thotton <sthotton@marvell.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Add all necessary elements for DPDK to compile and run EAL on SiFive
Freedom U740 SoC which is based on SiFive U74-MC (ISA: rv64imafdc)
core complex.
This includes:
- EAL library implementation for rv64imafdc ISA.
- meson build structure for 'riscv' architecture. RTE_ARCH_RISCV define
is added for architecture identification.
- xmm_t structure operation stubs as there is no vector support in the
U74 core.
Compilation was tested on Ubuntu and Arch Linux using riscv64 toolchain.
Clang compilation currently not supported due to issues with missing
relocation relaxation.
Two rte_rdtsc() schemes are provided: stable low-resolution using rdtime
(default) and unstable high-resolution using rdcycle. User can override
the scheme by defining RTE_RISCV_RDTSC_USE_HPM=1 during compile time of
both DPDK and the application. The reasoning for this is as follows.
The RISC-V ISA mandates that clock read by rdtime has to be of constant
period and synchronized between all hardware threads within 1 tick
(chapter 10.1 in version 20191213 of RISC-V spec).
However this clock may not be of high-enough frequency for dataplane
uses. I.e. on HiFive Unmatched (FU740) it is 1MHz.
There is a high-resolution alternative in form of rdcycle which is
clocked at the core clock frequency. The drawbacks are that it may be
disabled during sleep (WFI), its frequency might change due to DVFS and
it is core-local and therefore cannot be used as a wall-clock. It can
however be used for micro-benchmarking user applications, similarly to
Aarch64's PMCCNTR PMU counter.
The platform is currently marked as linux-only because rte_cycles
implementation uses the timebase-frequency device-tree node read through
the proc file system. Such approach was chosen because Linux kernel
depends on the presence of this device-tree node.
The i40e PMD driver is disabled on RISC-V as the rv64gc ISA has no vector
operations.
The compilation of following modules has been disabled by this commit
and will be re-enabled in later commits as fixes are introduced:
net/ixgbe, net/memif, net/tap, example/l3fwd.
Sponsored-by: Frank Zhao <frank.zhao@starfivetech.com>
Sponsored-by: Sam Grove <sam.grove@sifive.com>
Signed-off-by: Michal Mazurek <maz@semihalf.com>
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Each build, meson would issue a warning reporting that the
"warning_level" setting should be used in place of adding -Wextra
directly to our build commands. Testing with meson 0.61 shows that the
only difference for gcc and clang builds between warning levels 1 and
2 is the addition of -Wextra, so we can remove the warning by deleting
our explicit set of Wextra and changing the build defaults to
warning_level 2.
Fixes: 524a0d5d66 ("build: enable extra warnings with meson")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Meson 0.61.1 is giving warnings that the calls to run_command do not
always explicitly specify if the result is to be checked or not, i.e.
there is a missing "check" parameter. This is because the default
behaviour without the parameter is due to change in the future.
We can fix these warnings by explicitly adding into each call whether
the result should be checked by meson or not. This patch therefore
adds in "check: false" to each run_command call where the result is
being checked by the DPDK meson.build code afterwards, and adds in
"check: true" to any calls where the result is currently unchecked.
Bugzilla ID: 921
Cc: stable@dpdk.org
Reported-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Jerin Jacob <jerinj@marvell.com>
Add support for Address Sanitizer (ASan) for PPC/POWER architecture.
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
This patch defines ASAN_SHADOW_OFFSET for arm64 according to the ASan
documentation. This offset should cover all arm64 VMAs supported by
ASan.
Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
The RTE_PORT_PCAP variable is used to signal libpcap availability,
though its name seems to refer to pcap support in the port library.
Prefer a generic name and add explicit link dependencies where needed.
Fixes: 7a944656b3 ("test/pcapng: test pcapng library")
Fixes: 2eccf6afbe ("bpf: add function to convert classic BPF to DPDK BPF")
Fixes: cbb44143be ("app/dumpcap: add new packet capture application")
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
This patch adds necessary hooks in the memory allocator for ASan.
This feature is currently available in DPDK only on Linux x86_64.
If other OS/architectures want to support it, ASAN_SHADOW_OFFSET must be
defined and RTE_MALLOC_ASAN must be set accordingly in meson.
Signed-off-by: Xueqin Lin <xueqin.lin@intel.com>
Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
AddressSanitizer [1] a.k.a. ASan is a widely-used debugging tool to
detect memory access errors.
It helps to detect issues like use-after-free, various kinds of buffer
overruns in C/C++ programs, and other similar errors, as well as
printing out detailed debug information whenever an error is detected.
ASan is integrated with gcc and clang and can be enabled via a meson
option: -Db_sanitize=address
See the documentation for details (especially regarding clang).
Enabling ASan has an impact on performance since additional checks are
added to generated binaries.
Enabling ASan with Windows is currently not supported in DPDK.
1: https://github.com/google/sanitizers/wiki/AddressSanitizer
Signed-off-by: Xueqin Lin <xueqin.lin@intel.com>
Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
RTE_MBUF_REFCNT_ATOMIC = 0 is not necessary for applications like
Seastar, where it's safe to assume that the mbuf refcnt is only
updated by a single core only.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Add an option to automatically discover the host's NUMA and CPU counts
and use those values for a non cross-build.
Give users the option to override the per-arch default values or values
from cross files by specifying them on the command line with -Dmax_lcores
and -Dmax_numa_nodes.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Windows EAL depends on some system libraries. They were linked using
add_project_link_arguments('-l<LIB>'), which prevented meson from adding
them to Libs.private of pkg-config file. As a result, applications using
pkg-config to find DPDK hit link errors, for example:
librte_eal.a(eal_windows_eal_debug.c.obj) : error LNK2019: unresolved
external symbol __imp_SymInitialize referenced in function
rte_dump_stack
Reference required libraries in EAL using ext_deps meson variable.
bus/pci and net/pcap depend on lib/eal and will pull them automatically.
Drop advapi32 dependency, as MinGW locates VirtualAlloc2() dynamically.
Fixes: 2a5d547a4a ("eal/windows: implement basic memory management")
Fixes: c91717eb75 ("eal/windows: support exit and panic")
Cc: stable@dpdk.org
Reported-by: William Tu <u9012063@gmail.com>
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Tested-by: William Tu <u9012063@gmail.com>
Install command on Windows for Meson >= 0.55.0 referenced the script
by a plain string, assuming the build directory to be directly under
the source tree root.
This resulted in an error when the assumption did not hold:
c:\python\python.exe: can't open file
'../buildtools/symlink-drivers-solibs.py':
[Errno 2] No such file or directory
Use files() to make a valid script path for any build directory.
Fixes: cd27047dbe ("build: support drivers symlink on Windows")
Cc: stable@dpdk.org
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Nick Connolly <nick.connolly@mayadata.io>
The symlink-drivers-solibs.sh script was disabled as part of 'install'
for Windows because there is no support for shell scripts. However,
this means that driver related DLLs are not present in the installed
'libdir' directory. Add a python script to perform the install and use
it for Windows if the version of meson supports using an external
program with add_install_script (>= 0.55.0).
On Windows, symbolic links are somewhat problematic since the
SeCreateSymbolicLinkPrivilege is required to be able to create them.
In addition, different cross-compilation environments handle symbolic
links differently, e.g. WSL, Msys2, Cygwin. Rather than trying to
distinguish these scenarios, the python script will perform a file copy
for any Windows specific names.
On Windows, the shared library outputs have different names depending
upon which toolset has been used to build them. The script currently
handles Clang and GCC.
On Linux the functionality is unchanged, but could be replaced with the
python script once the required minimum version of meson is >= 0.55.0.
Cc: stable@dpdk.org
Signed-off-by: Nick Connolly <nick.connolly@mayadata.io>
Tested-by: Narcisa Vasile <navasile@linux.microsoft.com>
Acked-by: Narcisa Vasile <navasile@linux.microsoft.com>
Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
The current meson option 'machine' should only specify the ISA, which is
not sufficient for Arm, where setting ISA implies other settings as well
(and is used in Arm configuration as such).
Use the existing 'platform' meson option to differentiate the type of
the build (native/generic) and set ISA accordingly, unless the user
chooses to override it with a new option, 'cpu_instruction_set'.
The 'machine' option set the ISA in x86 builds and set native/default
'build type' in aarch64 builds. These two new variables, 'platform' and
'cpu_instruction_set', now properly set both ISA and build type for all
architectures in a uniform manner.
The 'machine' option also doesn't describe very well what it sets. The
new option, 'cpu_instruction_set', is much more descriptive. Keep
'machine' for backwards compatibility.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Introduce an internal firmware loading helper to remove code duplication
in our drivers and handle xz compressed firmware by calling libarchive.
This helper tries to look for .xz suffixes so that drivers are not aware
the firmware has been compressed.
libarchive is set as an optional dependency: without libarchive, a
runtime warning is emitted so that users know there is a compressed
firmware.
Windows implementation is left as an empty stub.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: Igor Russkikh <irusskikh@marvell.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Tested-by: Haiyue Wang <haiyue.wang@intel.com>
Implement OS-dependent functions and enable build for Windows.
Account for different library name in Windows libpcap distributions.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
Switch from using tabs to 4 spaces for meson.build indentation, for the
basic infrastructure and tooling files, as well as doc and kernel
directories.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Add support for enabling or disabling drivers for Arm cross build. Do
not implement any enable/disable lists yet.
Enabling drivers is useful when building for an SoC where we only want
to build a few drivers. That way the list won't be too long.
Similarly, disabling drivers is useful when we want to disable only a
few drivers.
Both of these are advantageous mainly in aarch64 -> aarch64 (or arch ->
same arch) builds, where the build machine may have the required driver
dependencies, yet we don't want to build drivers for a specific SoC.
If enable_drivers is a non-empty list, build only those drivers,
otherwise build all drivers and add them to enable_drivers. If
disable_drivers is non-empty list, build all drivers specified in
enable_drivers except those in disable_drivers.
There are two drivers, bus/pci and bus/vdev, which break the build if
not enabled. Address this by always enabling these if the user disables
them or doesn't specify in their allowlist.
Also remove the old Makefile arm configuration options which don't do
anything in Meson.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The current machine='default' build name is not descriptive. The actual
default build is machine='native'. Add an alternative string which does
the same build and better describes what we're building:
machine='generic'. Leave machine='default' for backwards compatibility.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The library execinfo and its header file can be installed on Alpine Linux
where the backtrace feature is not part of musl libc:
apk add libexecinfo-dev
As a consequence, this library should not be restricted to BSD only.
At the same time, the library and header are detected once and added
globally to be linked with any application, internal or external.
Fixes: 9065b1fac6 ("build: fix dependency on execinfo for BSD meson builds")
Cc: stable@dpdk.org
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: David Marchand <david.marchand@redhat.com>
Meson can use cmake as a fallback for detecting packages, and this can
lead to picking up 64-libs for 32-bit builds. To work around this, force
the use of pkg-config only for detecting libcrypto, zlib, jansson and
other package dependencies.
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Ruifeng Wang <ruifeng.wang@arm.com>
Tested-by: Liron Himi <lironh@marvell.com>
Tested-by: Lee Daly <lee.daly@intel.com>
Tested-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Tested-by: Martin Spinler <spinler@cesnet.cz>
Rather than having the DPDK configuration error out when linking apps
and examples when "both" is select for "default_library" option, we can
detect that setting earlier in the build config and provide a suitable
error message to the user.
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Andrew Boyer <aboyer@pensando.io>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
As announced in the deprecation note, remove all compatibility build
defines from previous make/meson versions and use only the standardized
ones - RTE_LIB_<name> for libraries, and RTE_<CLASS>_<NAME> for drivers.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Some Arm SoCs are not NUMA systems. Add the capability to disable NUMA
for cross build and disable NUMA in Arm cross files.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Tested-by: Jerin Jacob <jerinj@marvell.com>
Tested-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Tested-by: Vimal Chungath <vcchunga@amazon.com>
Tested-by: Dharmik Thakkar <dharmik.thakkar@arm.com>
Add support for setting core count and numa nodes in cross files. The
values specified in cross files will override the default values.
Also add missing default values to Arm config.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Tested-by: Jerin Jacob <jerinj@marvell.com>
Tested-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Tested-by: Vimal Chungath <vcchunga@amazon.com>
Tested-by: Dharmik Thakkar <dharmik.thakkar@arm.com>
Microsoft CRT defines Windows-specific secure alternatives to
standard library functions and triggers warnings when "insecure"
functions are used [1]. However, calling code already has all
necessary checks around those functions, so these warnings are not
useful for DPDK. MinGW provides its own CRT without this issue.
[1]:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt?view=msvc-160
Disable this by defining -D_CRT_SECURE_NO_WARNINGS.
Signed-off-by: Nick Connolly <nick.connolly@mayadata.io>
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Pallavi Kadam <pallavi.kadam@intel.com>
On some CentOS/RHEL systems using gcc 8.3.1 to compile dpdk, gcc shows a
warning on every build step saying that -Wformat-nonliteral and
-Wformat-security warnings will be ignored unless -Wformat is
also specified as a compiler flag. When the build is run with -werror
the build will fail due to these warnings.
Exact warning returned:
cc1: error: -Wformat-nonliteral ignored without -Wformat
[-Werror=format-nonliteral]
cc1: error: -Wformat-security ignored without -Wformat
[-Werror=format-security]
cc1: all warnings being treated as errors
This patch adds the -Wformat flag to config/meson.build. The warning id
181 has also been suppressed in icc as icc was showing false positives
with -Wformat enabled.
Fixes: 524a0d5d66 ("build: enable extra warnings with meson")
Cc: stable@dpdk.org
Signed-off-by: Conor Walsh <conor.walsh@intel.com>
Tested-by: Lingli Chen <linglix.chen@intel.com>
Don't run symlink-drivers-solibs.sh as part of 'install' because
Windows doesn't support shell scripts.
Fixes: 82ba4416dd ("build: add module definition files for Windows")
Cc: stable@dpdk.org
Signed-off-by: Nick Connolly <nick.connolly@mayadata.io>
Tested-by: Ranjit Menon <ranjit.menon@intel.com>
Acked-by: Ranjit Menon <ranjit.menon@intel.com>
The defines used to indicate what crypto, compression and eventdev drivers
were being built were different to those used in the make build, with meson
defining them with "_PMD" at the end, while make defined them with "_PMD"
in the middle and the specific driver name at the end. This might cause
compatibility issues for applications which used the older defines, which
switching to build against new DPDK releases.
As well as changing the default to match that of make, meson also
special-cases the crypto/compression/event drivers to have both defines
provided. This ensures compatibility for these macros with both meson and
make from older versions.
For a selection of other libraries and drivers, there were other
incompatibilities between the meson and make-defined macros which were not
previously highlighted in a deprecation notice, so we add per-macro
compatibility defines for these to ease the transition from make to meson.
Fixes: 5b9656b157 ("lib: build with meson")
Fixes: 9314afb68a ("drivers: add infrastructure for meson build")
Fixes: dcadbbde8e ("crypto/null: build with meson")
Fixes: 3c32e89f68 ("compress/isal: add skeleton ISA-L compression PMD")
Fixes: eca504f318 ("drivers/event: build skeleton and SW drivers with meson")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Implement terminal handling, input polling, and vdprintf() for Windows.
Because Windows I/O model differs fundamentally from Unix and there is
no concept of character device, polling is simulated depending on the
underlying input device. Supporting non-terminal input is useful for
automated testing.
Windows emulation of VT100 uses "ESC [ E" for newline instead of
standard "ESC E", so add a workaround.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
RTE_ARCH_xx flags are used to distinguish platform architectures.
These flags can be used to pick different code paths for different
architectures at compile time.
For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM,
RTE_ARCH_ARMv7 and RTE_ARCH_ARM64.
RTE_ARCH_ARM64 is for 64-bit aarch64 platforms,
and RTE_ARCH_ARM & RTE_ARCH_ARMv7 are for 32-bit platforms.
RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested.
The issue is meaning of RTE_ARCH_ARM is not clear enough.
Because no info about platform word length is included in the name.
To make the flag names more clear, a naming scheme is proposed.
RTE_ARCH_ARM (all Arm platforms)
|
+----RTE_ARCH_32 (New. 32-bit platforms of all architectures)
| |
| +----RTE_ARCH_ARMv7 (ARMv7 platforms)
| |
| +----RTE_ARCH_ARMv8_AARCH32 (aarch32 state on aarch64 machine)
|
+----RTE_ARCH_64 (64-bit platforms of all architectures)
|
+----RTE_ARCH_ARM64 (64-bit Arm platforms)
RTE_ARCH_32 will be explicitly defined for 32-bit platforms.
To fit into the new naming scheme, current usage of RTE_ARCH_ARM in
project is mapped to (RTE_ARCH_ARM && RTE_ARCH_32).
Matching flags for other architectures are:
RTE_ARCH_X86
|
+----RTE_ARCH_32
| |
| +----RTE_ARCH_I686
| |
| +----RTE_ARCH_X86_X32
|
+----RTE_ARCH_64
|
+----RTE_ARCH_X86_64
RTE_ARCH_PPC_64 ---- RTE_ARCH_64
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Phil Yang <phil.yang@arm.com>
When compiling for a slightly different architecture, e.g. 32-bit on 64-bit
systems using CFLAGS rather than a cross-file, the pcap-config utility can
often return parameters that are unusable for the build in question, i.e.
providing the native 64-bit library paths rather than checking for 32-bit
equivalent.
Since many distros now include a version of libpcap with a
pkg-config file, and for those that don't find-library should work ok as a
fallback, we can explicitly just use pkg-config in the dependency search,
causing meson to skip trying to use pcap-config.
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Luca Boccassi <bluca@debian.org>
Tested-by: David Marchand <david.marchand@redhat.com>
The checks for libfdt try dependency() first which would only work if
a pkg-config would be present but libfdt has none.
Then it probes for the lib path itself via cc.find_library.
But later it adds the result of either probe to ext_deps which ends up
in build and also the resulting pkg-config to contain toolchain versioned
paths in Libs.private like:
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libfdt.so
which obviously breaks on toolchain updates.
In general libs used multiple times - ipn3ke + ifpga in this case - are
checked centrally in config/meson.build so move it there and fix the
adding of dependencies to not use the full file path.
The result is libfdt in pkg-config now showing up as:
Libs.private: -pthread -lm -ldl -lnuma -lfdt -lpcap
Fixes: e1defba4cf ("raw/ifpga/base: support device tree")
Cc: stable@dpdk.org
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Reviewed-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
Start a new release cycle with empty release notes.
The ABI version becomes 21.0.
The ABI major is back to normal, having only one number (21 vs 20.0).
The map files are updated to the new ABI major number (21).
The ABI exceptions are dropped.
Travis ABI check is disabled because compatibility is not preserved.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Having a special versioning for experimental/internal libraries put a
additional maintenance cost while this status is already announced in
MAINTAINERS and the library headers/documentation.
Following discussions and vote at 05/20 TB meeting [1], use a single
versioning for all libraries in DPDK.
Note: for the ABI check, an exception [2] had been added when tweaking
this special versioning [3].
Prefer explicit libabigail rules (which will be dropped in 20.11).
1: https://mails.dpdk.org/archives/dev/2020-May/168450.html
2: https://git.dpdk.org/dpdk/commit/?id=23d7ad5db41c
3: https://git.dpdk.org/dpdk/commit/?id=ec2b8cd7ed69
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
When building with meson, the default size of virtual address space
reserved for mapping pages was globally set at 512GB, which is too big for
use in 32-bit processes. To match the behaviour with "make", we configure
this to be 512GB for 64-bit and 2GB for 32-bit builds.
Bugzilla ID: 498
Fixes: 66cc45e293 ("mem: replace memseg with memseg lists")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Support the debug functions in eal_common_debug.c for Windows.
Implementation of rte_dump_stack to get a backtrace similarly to Unix
and of rte_eal_cleanup in eal.c.
Signed-off-by: Tal Shnaiderman <talshn@mellanox.com>
Tested-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Even if pthread is provided by the toolchain, it is not needed for DPDK
on Windows, because internal shim is used. As a side-effect, this
enables cross-build with MinGW configured with non-POSIX thread library,
e.g. mcfgthread, which is the default on some distributions.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Pallavi Kadam <pallavi.kadam@intel.com>
Basic memory management supports core libraries and PMDs operating in
IOVA as PA mode. It uses a kernel-mode driver, virt2phys, to obtain
IOVAs of hugepages allocated from user-mode. Multi-process mode is not
implemented and is forcefully disabled at startup. Assign myself as a
maintainer for Windows file and memory management implementation.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Add hugepages discovery ("large pages" in Windows terminology)
and update documentation for required privilege setup. Only 2MB
hugepages are supported and their number is estimated roughly
due to the lack or unstable status of suitable OS APIs.
Assign myself as maintainer for the implementation file.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
gcc 10 issues warnings about the use of rearm_data marker
from struct rte_mbuf.
e.g.
../drivers/net/enic/enic_rxtx_vec_avx2.c: In function ‘rx_one’:
../drivers/net/enic/enic_rxtx_vec_avx2.c:21:2:
warning:
array subscript 0 is outside the bounds of an interior zero-length array
‘RTE_MARKER64’ {aka ‘long unsigned int[0]’} [-Wzero-length-bounds]
21 | *(uint64_t *)&mb->rearm_data = enic->mbuf_initializer;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../lib/librte_mbuf/rte_mbuf.h:45,
from ../drivers/net/enic/enic_rxtx_vec_avx2.c:6:
../lib/librte_mbuf/rte_mbuf_core.h:484:15:
note: while referencing ‘rearm_data’
484 | RTE_MARKER64 rearm_data;
|
Disable this warning for gcc 10 in order to allow v20.05 to build
without changes to struct rte_mbuf.
Bugzilla ID: 396
Cc: stable@dpdk.org
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
The global include path, which is used by anything built before EAL,
points to the EAL header files so they utility macros etc. can be used
anywhere in DPDK. This path included the OS-specific EAL header files,
but not the architecture-specific ones. This patch moves the selection
of target architecture to the top-level meson.build file so that the
global include can reference that.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Keith Wiles <keith.wiles@intel.com>
Define the public API for trace support.
This patch also adds support for the build infrastructure and
update the MAINTAINERS file for the trace subsystem.
The 8 bytes tracepoint object is a global variable, and can be used in
fast path. Created a new __rte_trace_point section to store the
tracepoint objects as,
- It is a mostly read-only data and not to mix with other "write"
global variables.
- Chances that the same subsystem fast path variables come in the same
fast path cache line. i.e, it will enable a more predictable
performance number from build to build.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
Acked-by: David Marchand <david.marchand@redhat.com>
Add libatomic as a global dependency when compiling for 32-bit using
clang. As we need libatomic for 64-bit atomic ops.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The directories ppc_64 are renamed as ppc in
- config/
- lib/librte_eal/common/arch/
- lib/librte_eal/common/include/arch/
The EAL directories are not really renamed, but symbolically linked,
because they will be moved with their new name in the next commits.
If ppc_32 needs to be supported, it can be in the same directory.
The arch directories arm and x86 are already covering both 32 and 64-bit
sub-architectures.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Acked-by: David Marchand <david.marchand@redhat.com>
Clang on Windows doesn't use pthread for now, while MinGW does. Removing
`-pthread` option with MS linker fixes the following warning:
clang: warning: argument unused during compilation: '-pthread'
[-Wunused-command-line-argument]
Option `--no-as-needed` is meaningless for PE output. Disabling it on
Windows fixes the following warning:
LINK : warning LNK4044: unrecognized option '/-no-as-needed'; ignored
Fixes: 98edcbb5a ("eal/windows: introduce Windows support")
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Tested-by: William Tu <u9012063@gmail.com>
Tested-by: Pallavi Kadam <pallavi.kadam@intel.com>
Acked-by: Pallavi Kadam <pallavi.kadam@intel.com>
MinGW-w64 linker does not mimic MS linker options, so the build system
must differentiate between linkers on Windows. Use GNU linker options
with GCC and MS linker options with Clang.
MinGW-w64 by default uses MSVCRT stdio, which does not comply to ANSI,
most notably its formatting and string handling functions. MinGW-w64
support for the Universal CRT (UCRT) is ongoing, but the toolchain
provides its own standard-complying implementation of stdio. The latter
is used in the patch to support formatting in DPDK.
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Tested-by: William Tu <u9012063@gmail.com>
Tested-by: Pallavi Kadam <pallavi.kadam@intel.com>
