Add all necessary elements for DPDK to compile and run EAL on
LoongArch64 Soc.
This includes:
- EAL library implementation for LoongArch ISA.
- meson build structure for 'loongarch' architecture.
RTE_ARCH_LOONGARCH define is added for architecture identification.
- xmm_t structure operation stubs as there is no vector support in
the current version for LoongArch.
Compilation was tested on Debian and CentOS using loongarch64
cross-compile toolchain from x86 build hosts. Functions were tested
on Loongnix and Kylin which are two Linux distributions supported
LoongArch host based on Linux 4.19 maintained by Loongson
Corporation.
We also tested DPDK on LoongArch with some external applications,
including: Pktgen-DPDK, OVS, VPP.
The platform is currently marked as linux-only because there is no
other OS than Linux support LoongArch host currently.
The i40e PMD driver is disabled on LoongArch because of the absence
of vector support in the current version.
Similar to RISC-V, 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.
Signed-off-by: Min Zhou <zhoumin@loongson.cn>
Added changes to enable CMAN (RED or PIE) at init
from profile configuration file.
By default CMAN code is enabled but not in use, when
there is no RED or PIE profile configured.
Signed-off-by: Marcin Danilewicz <marcinx.danilewicz@intel.com>
Acked-by: Jasvinder Singh <jasvinder.singh@intel.com>
Here adds configs for Phytium server.
Signed-off-by: Zhipeng Lu <luzhipeng@cestc.cn>
Reviewed-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
Through some mixup all cross-files for ARM and PowerPC platforms were
using C Preprocessor (cpp) instead of GCC (g++).
This caused meson to fail detecting the C++ compiler presence and
therefore disabling some targets (i.e. C++ include file checks).
Fixes: e53a5299d2 ("build: support vendor specific ARM cross builds")
Cc: stable@dpdk.org
Signed-off-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Rather than explicitly clearing any setting of undefined values in our
rte_config.h file, it's better to instead just add a comment that the
value is not set. Using a comment allows the user to set the value using
CFLAGS or similar mechanism without the config file clearing the value
again.
The text used "<VALUE> is not set" is modelled after the kernel approach
of doing the same thing.
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>
Signed-off-by: David Marchand <david.marchand@redhat.com>
By default, ccache is not used for cross build[1].
Update all cross files to use ccache if it is available
in build machine.
Also, updated devtools/test-meson-builds.sh
script to find the correct DPDK_TARGET due to
change in cross file syntax.
[1]
https://mesonbuild.com/Machine-files.html
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Stanislaw Kardach <kda@semihalf.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.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>
This disable the sve_acle flag for cn10k.
For native build, -Dplatform=cn10k will require to
get sve_acle flag parameter in the build.
Performance impact:-
With l3fwd example, lpm lookup performance increased
by ~21% if Neon is used instead of SVE. Hence, disabled
sve_acle flag for cn10k.
Signed-off-by: Rahul Bhansali <rbhansali@marvell.com>
Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
An additional check of control flag sve_acle for
RTE_HAS_SVE_ACLE macro to be part of the build.
If any SoC config doesn't have sve_acle flag parameter
then default it will be considered as true.
Signed-off-by: Rahul Bhansali <rbhansali@marvell.com>
Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
Reviewed-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
Ubuntu 18.04 is now rather old.
Besides, other entities in our CI are also testing this distribution.
Switch to a newer Ubuntu release and benefit from more recent
tool(chain)s: for example, net/cnxk now builds fine and can be
re-enabled.
Note: Ubuntu 18.04 and 20.04 seem to preserve the same paths for the ARM
and PPC cross compilation toolchains, so we can use a single
configuration file (with the hope, future releases of Ubuntu will do the
same).
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Removed RTE_SCHED_SUBPORT_TC_OV from rte_config.h.
Best effort traffic class oversubscription is always enabled.
Signed-off-by: Megha Ajmera <megha.ajmera@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Grinder configuration is now moved to sched library.
Number of grinders can also modified by specifying
RTE_SCHED_PORT_N_GRINDERS=N in CFLAGS, where N is number of grinders.
Signed-off-by: Megha Ajmera <megha.ajmera@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Remove RTE_SCHED_VECTOR flag from rte_config.h.
This flag is no longer useful. Only scalar version is supported.
Signed-off-by: Megha Ajmera <megha.ajmera@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Mempool elements are by default aligned to CACHELINE_SIZE.
In CN10K cacheline size is 64B but the RoC requires buffers to be
aligned to 128B.
Set RTE_MEMPOOL_ALIGN to 128 to force mempool buffers to be aligned
128 bytes.
Fixes: 1b4c86a721 ("config/arm: add Marvell CN10K")
Cc: stable@dpdk.org
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Armv7 native build fails with this error:
../config/meson.build:364:1: ERROR: Problem encountered:
Number of CPU cores not specified.
This is because RTE_MAX_LCORE is not set. We also need to set
RTE_MAX_NUMA_NODES in armv7 native builds.
Fixes: 8ef09fdc50 ("build: add optional NUMA and CPU counts detection")
Cc: stable@dpdk.org
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
The Kni kthreads seem to be re-scheduled at a granularity of roughly
1 millisecond right now, which seems to be insufficient for performing
tests involving a lot of control plane traffic.
Even if KNI_KTHREAD_RESCHEDULE_INTERVAL is set to 5 microseconds, it
seems that the existing code cannot reschedule at the desired granularily,
due to precision constraints of schedule_timeout_interruptible().
In our use case, we leverage the Linux Kernel for control plane, and
it is not uncommon to have 60K - 100K pps for some signaling protocols.
Since we are not in atomic context, the usleep_range() function seems to be
more appropriate for being able to introduce smaller controlled delays,
in the range of 5-10 microseconds. Upon reading the existing code, it would
seem that this was the original intent. Adding sub-millisecond delays,
seems unfeasible with a call to schedule_timeout_interruptible().
KNI_KTHREAD_RESCHEDULE_INTERVAL 5 /* us */
schedule_timeout_interruptible(
usecs_to_jiffies(KNI_KTHREAD_RESCHEDULE_INTERVAL));
Below, we attempted a brief comparison between the existing implementation,
which uses schedule_timeout_interruptible() and usleep_range().
We attempt to measure the CPU usage, and RTT between two Kni interfaces,
which are created on top of vmxnet3 adapters, connected by a vSwitch.
insmod rte_kni.ko kthread_mode=single carrier=on
schedule_timeout_interruptible(usecs_to_jiffies(5))
kni_single CPU Usage: 2-4 %
[root@localhost ~]# ping 1.1.1.2 -I eth1
PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 eth1: 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.70 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.00 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.99 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.985 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.00 ms
usleep_range(5, 10)
kni_single CPU usage: 50%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.338 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.123 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.139 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.159 ms
usleep_range(20, 50)
kni_single CPU usage: 24%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.170 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.171 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.248 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.185 ms
usleep_range(50, 100)
kni_single CPU usage: 13%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.537 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.257 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.231 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.143 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.200 ms
usleep_range(100, 200)
kni_single CPU usage: 7%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.716 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.167 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.459 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.455 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.252 ms
usleep_range(1000, 1100)
kni_single CPU usage: 2%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.22 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.15 ms
Upon testing, usleep_range(1000, 1100) seems roughly equivalent in
latency and cpu usage to the variant with schedule_timeout_interruptible(),
while usleep_range(100, 200) seems to give a decent tradeoff between
latency and cpu usage, while allowing users to tweak the limits for
improved precision if they have such use cases.
Disabling RTE_KNI_PREEMPT_DEFAULT, interestingly seems to lead to a
softlockup on my kernel.
Kernel panic - not syncing: softlockup: hung tasks
CPU: 0 PID: 1226 Comm: kni_single Tainted: G W O 3.10 #1
<IRQ> [<ffffffff814f84de>] dump_stack+0x19/0x1b
[<ffffffff814f7891>] panic+0xcd/0x1e0
[<ffffffff810993b0>] watchdog_timer_fn+0x160/0x160
[<ffffffff810644b2>] __run_hrtimer.isra.4+0x42/0xd0
[<ffffffff81064b57>] hrtimer_interrupt+0xe7/0x1f0
[<ffffffff8102cd57>] smp_apic_timer_interrupt+0x67/0xa0
[<ffffffff8150321d>] apic_timer_interrupt+0x6d/0x80
This patch also attempts to remove this option.
References:
[1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
Signed-off-by: Tudor Cornea <tudor.cornea@gmail.com>
Acked-by: Padraig Connolly <Padraig.J.Connolly@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.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>
As per design document, RTE_ARCH is the name of the architecture.
However, the definition was missing on Arm with meson build.
It impacts applications that refers to this string.
Added for Arm builds.
Fixes: b1d48c4118 ("build: support ARM with meson")
Cc: stable@dpdk.org
Reported-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
As per the deprecation notice, In the view of enabling unified driver
for octeontx2(cn9k)/octeontx3(cn10k), removing drivers/octeontx2
drivers and replace with drivers/cnxk/ which
supports both octeontx2(cn9k) and octeontx3(cn10k) SoCs.
This patch does the following
- Replace drivers/common/octeontx2/ with drivers/common/cnxk/
- Replace drivers/mempool/octeontx2/ with drivers/mempool/cnxk/
- Replace drivers/net/octeontx2/ with drivers/net/cnxk/
- Replace drivers/event/octeontx2/ with drivers/event/cnxk/
- Replace drivers/crypto/octeontx2/ with drivers/crypto/cnxk/
- Rename config/arm/arm64_octeontx2_linux_gcc as
config/arm/arm64_cn9k_linux_gcc
- Update the documentation and MAINTAINERS to reflect the same.
- Change the reference to OCTEONTX2 as OCTEON 9. Old release notes and
the kernel related documentation is not accounted for this change.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
Cross build with MinGW was broken for the baseline meson 0.49.2.
Cause: in c_args = '-mno-avx512f' from config/x86/cross-mingw,
each character was treated as a separate compiler option:
meson.build:4:0: ERROR: Compiler x86_64-w64-mingw32-gcc can not compile programs.
With c_args = ['-mno-avx512f'] configuration passed, but build failed,
because Meson placed -mno-avx512f after -mavx512f in CFLAGS:
In file included from /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/immintrin.h:55,
from /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/x86intrin.h:32,
from ../dpdk/lib/net/net_crc_avx512.c:13:
/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/avx512fintrin.h:1650:1:
error: inlining failed in call to always_inline _mm512_ternarylogic_epi64:
target specific option mismatch
1650 | _mm512_ternarylogic_epi64 (__m512i __A, __m512i __B, __m512i __C,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
../dpdk/lib/net/net_crc_avx512.c:59:9: note: called from here
59 | return _mm512_ternarylogic_epi64(tmp0, tmp1, data_block, 0x96);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additionally, -m[no-]avx512f flag is expected to be in machine_args
by all the checks in meson.build files.
Commit 419c6e9af6 ("net/i40e: fix build for Windows MinGW")
fixed the errors cause by MinGW using AVX512F on Windows.
The binutils AVX512F bug check is now portable,
so enable it for Windows to switch AVX512 support on and off
without any special logic for MinGW.
Fixes: 549bfc8316 ("config: disable AVX512 with MinGW")
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
AVX512 was disabled when GNU binutils were missing or had a known bug,
even if LLVM binutils were used for the build,
because binutils-avx512-check.sh was invoked regardless and failed.
In particular, this was the case for FreeBSD with clang (default).
Run the check only when GNU binutils are used.
Fixes: 68b1f1cda5 ("build: check AVX512 rather than binutils version")
Cc: stable@dpdk.org
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.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>
Enable Github Actions to cross-compile code for POWER systems.
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
Reviewed-by: David Marchand <david.marchand@redhat.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>
Increase default value for config parameter RTE_LIBRTE_IP_FRAG_MAX_FRAG
from 4 to 8. This parameter controls maximum number of fragments per
packet in ip reassembly table. Increasing this value from 4 to 8 will
allow users to cover common case with jumbo packet size of 9KB and
fragments with default frame size (1500B).
As RTE_LIBRTE_IP_FRAG_MAX_FRAG is used in definition of public
structure (struct rte_ip_frag_death_row), this is an ABI change.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Aarch32 config got overlooked when splitting march in a previous patch.
Fixes: 95e0f23022 ("config/arm: split -march into arch and features")
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
Implement PIE based congestion management based on rfc8033.
The Proportional Integral Controller Enhanced (PIE) algorithm works
by proactively dropping packets randomly.
PIE is implemented as more advanced queue management is required to
address the bufferbloat problem and provide desirable quality of
service to users.
Tests for PIE code added to test application.
Added PIE related information to documentation.
Signed-off-by: Wojciech Liguzinski <wojciechx.liguzinski@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Jasvinder Singh <jasvinder.singh@intel.com>
The POWER meson.build file incorrectly checks if the detected CPU is
"greater than" POWER8 when it should actually test for "greater than or
equal to" POWER8. Fixed the comparison operator.
Bugzilla ID: 875
Fixes: 7501968808 ("config/ppc: select instruction set for IBM Power10")
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
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>
Allocate max space for internal port, port config, queue config and
link map arrays.
Introduce new macro RTE_EVENT_MAX_PORTS_PER_DEV and set it to max
possible value.
This simplifies the port and queue reconfigure scenarios and will
also allow inline functions to refer pointer to internal port data
without extra checking of current number of configured queues.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Common octeontx2 code shares some of the PCI identifiers
with cn10k platform and if built wrong drivers may be probed.
octeontx2 configuration disables common cn10k code so disable
common octeontx2 on cn10k.
Signed-off-by: Tomasz Duszynski <tduszynski@marvell.com>
Reviewed-by: Jerin Jacob <jerinj@marvell.com>
For native build, enabling building the highest cpu_instruction_set
supported by the build host, including the new POWER10.
For cross compile, verifying that the compiler supports the
cpu_instruction_set specified in the cross-file
Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Not all Neoverse-N2 CPUs must support the crypto feature/extension
which makes it an optional feature.
Only enable the feature for SoCs which support it.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Older compilers may not support all arch versions and all features that
the target SoC supports, in which case it's better to figure out the
highest arch version and features that the compiler supports.
Implement a way to achieve this:
1. Find the highest arch version that the compiler supports,
keeping in mind the SoC arch version we're building.
For example, if the SoC arch version is arm8.2-a,
but the compiler only supports arm8.1-a, use arm8.1-a.
On the other hand, if the compiler supports arm8.3-a (or higher),
use armv8.2-a.
2. With the architecture version locked, iterate over SoC features and
use all that are supported.
In all cases, emit a warning if there's something unsupported by the
compiler.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
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>
Like for python, multiline statements in meson must either use a
backslash character (explicit continuation) or be enclosed in ()
(implicit continuation).
python PEP8 recommends the latter [1], and it looks like meson had
an issue with backslash before 0.50 [2].
1: https://www.python.org/dev/peps/pep-0008/#multiline-if-statements
2: https://github.com/mesonbuild/meson/commit/90c9b868b20b
Fixes: 394407f50c ("config/ppc: ignore GCC 11 psabi warnings")
Reported-by: Ferruh Yigit <ferruh.yigit@intel.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.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>
Suppress the gcc warning "note: the layout of aggregates containing
vectors with 4-byte alignment has changed in GCC 5" on POWER systems
by setting "-Wno-psabi". Warning was originally added to gcc in
commit https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9832651 to warn
of the vector alignment changes introduced in GCC 5. Older gcc
versions forced vector alignment to 16 bytes due to requirements for
POWER 6 and earlier CPUs, but these restrictions don't apply to CPUs
supported by DPDK.
Bugzilla ID: 739
Cc: stable@dpdk.org
Signed-off-by: David Christensen <drc@linux.vnet.ibm.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>
GCC 6.3.0 has a known bug which related to _mm512_extracti64x4_epi64.
Please reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82887
Some DPDK PMD AVX512 version heavily use _mm512_extracti64x4_epi6,
which cause building failure with debug buildtype.
Therefore, it's helpful to check if compiler work with
_mm512_extracti64x4_epi6.
This patch check the compiler compile result against the test code
snippet. If the checking is failed then disable AVX512.
Bugzilla ID: 717
Fixes: e6a6a13891 ("net/i40e: add AVX512 vector path")
Fixes: 808a17b3c1 ("net/ice: add Rx AVX512 offload path")
Fixes: 4b64ccb328 ("net/iavf: fix VLAN extraction in AVX512 path")
Cc: stable@dpdk.org
Reported-by: Liang Ma <liangma@liangbit.com>
Signed-off-by: Liang Ma <liangma@bytedance.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'),
and the compiler is gcc-8.3, it will produce this error:
In file included from lib/eal/common/eal_common_options.c:38:
lib/eal/arm/include/rte_vect.h:13:10: fatal error:
arm_sve.h: No such file or directory
#include <arm_sve.h>
^~~~~~~~~~~
The root cause is that gcc-8.3 supports SVE (the macro
__ARM_FEATURE_SVE was 1), but it doesn't support SVE ACLE [1].
The solution:
a) Detect compiler whether support SVE ACLE, if support then define
RTE_HAS_SVE_ACLE macro.
b) Use the RTE_HAS_SVE_ACLE macro to include SVE header file.
[1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
<arm_sve.h>, user should include it when writing ACLE SVE code.
Fixes: 67b68824a8 ("lpm/arm: support SVE")
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Create meson cross file arm32_armv8a_linux_gcc. Use arm-linux-gnueabihf-
toolset which comes with standard packages on most used systems, such as
Ubuntu and CentOS.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
