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>
Building DPDK on Ubuntu 20.04 with GCC 9.3.0 results in a "subscript is
outside array bounds" message in rte_memcpy function. The build error
is caused by an interaction between __builtin_constant_p and
"-Werror=array-bounds" as described in this bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387
Modify the code to disable the array-bounds check for GCC versions 9.0
to 9.3.
Cc: stable@dpdk.org
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
The AltiVec header file breaks boolean type. [1] [2]
Currently the workaround was located only in mlx5 device.
Adding the trace module caused this issue to appear again, due to
order of includes, it keeps overriding the local fix.
This patch solves this issue by resetting the bool type, immediately
after it is being changed.
[1] https://mails.dpdk.org/archives/dev/2018-August/110281.html
[2]
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18:0,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h: In
function '__rte_trace_point_fp_is_enabled':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:226:2:
error: incompatible types when returning type 'int' but '__vector __bool
int' was expected
return false;
^
In file included from
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:281:0,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:18,
from
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool.h:54,
from
dpdk/drivers/common/mlx5/mlx5_common_mr.c:7:
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
__rte_trace_point_emit_header_##_mode(&__##_tp); \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
__RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:20:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
RTE_TRACE_POINT_FP(
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_dequeue_contig_blocks':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:49:2:
note: in expansion of macro '__rte_trace_point_emit_header_fp'
__rte_trace_point_emit_header_##_mode(&__##_tp); \
^
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point.h:99:2:
note: in expansion of macro '__RTE_TRACE_POINT'
__RTE_TRACE_POINT(fp, tp, args, __VA_ARGS__)
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:29:1:
note: in expansion of macro 'RTE_TRACE_POINT_FP'
RTE_TRACE_POINT_FP(
^
dpdk/ppc_64-power8-linux-gcc/include/rte_mempool_trace_fp.h:
In function 'rte_mempool_trace_ops_enqueue_bulk':
dpdk/ppc_64-power8-linux-gcc/include/rte_trace_point_provider.h:104:6:
error: wrong type argument to unary exclamation mark
if (!__rte_trace_point_fp_is_enabled()) \
Fixes: 725f5dd0bfb5 ("net/mlx5: fix build on PPC64")
Signed-off-by: Ori Kam <orika@mellanox.com>
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
Tested-by: David Christensen <drc@linux.vnet.ibm.com>
Tested-by: Raslan Darawsheh <rasland@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
__ppc_get_timebase() reads and returns the current value of the Time
Base Register. It's more efficient as it uses the processor’s time
base facility directly.
DPDK on FreeBSD currently is not supported on Powerpc64, it should
be safe to include the sys/platform/ppc.h.
Signed-off-by: Thinh Tran <thinhtr@linux.vnet.ibm.com>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Compilation is broken on ppc:
CC otx2_rx.o
In file included from .../drivers/net/octeontx2/otx2_rx.c:5:0:
.../builds/ppc_64-power8-linux-gcc/include/rte_vect.h:29:17:
error: expected declaration specifiers or ‘...’ before numeric constant
} __rte_aligned(16) rte_xmm_t;
^~
compilation terminated due to -Wfatal-errors.
Fixes: f35e5b3e07b2 ("replace alignment attributes")
Signed-off-by: David Marchand <david.marchand@redhat.com>
Tested-by: Thomas Monjalon <thomas@monjalon.net>
There is a common macro __rte_aligned for alignment,
which is now used where appropriate for consistency.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
The arch-specific directories arm, ppc and x86 in common/include/arch/
are moved as include/ sub-directories of respective arch directories:
- arm/include/
- ppc/include/
- x86/include/
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
Reviewed-by: David Christensen <drc@linux.vnet.ibm.com>
Acked-by: David Marchand <david.marchand@redhat.com>
The arch-specific directories arm, ppc and x86 in common/arch/
are moved at the same level as the OS-specific directories.
It makes more clear that EAL is covering a matrix combining OS and arch.
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>
