[ upstream commit f5bf02df3145f95b1ee8ed9dee67f4222ac42c8c ] 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> --- drivers/net/i40e/i40e_rxtx_vec_altivec.c | 2 +- drivers/net/mlx5/mlx5_rxtx_vec_altivec.h | 2 +- drivers/net/mlx5/mlx5_utils.h | 10 ---------- drivers/net/virtio/virtio_rxtx_simple_altivec.c | 3 +-- .../common/include/arch/ppc_64/meson.build | 1 + .../common/include/arch/ppc_64/rte_memcpy.h | 4 ++-- .../common/include/arch/ppc_64/rte_vect.h | 3 ++- lib/librte_eal/ppc/include/rte_altivec.h | 22 ++++++++++++++++++++++ 8 files changed, 30 insertions(+), 17 deletions(-) create mode 100644 lib/librte_eal/ppc/include/rte_altivec.h diff --git a/drivers/net/i40e/i40e_rxtx_vec_altivec.c b/drivers/net/i40e/i40e_rxtx_vec_altivec.c index 310ce1e..5406828 100644 --- a/drivers/net/i40e/i40e_rxtx_vec_altivec.c +++ b/drivers/net/i40e/i40e_rxtx_vec_altivec.c @@ -13,7 +13,7 @@ #include "i40e_rxtx.h" #include "i40e_rxtx_vec_common.h" -#include <altivec.h> +#include <rte_altivec.h> #pragma GCC diagnostic ignored "-Wcast-qual" diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h b/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h index 23ffb8d..feb17fe 100644 --- a/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h +++ b/drivers/net/mlx5/mlx5_rxtx_vec_altivec.h @@ -11,7 +11,7 @@ #include <string.h> #include <stdlib.h> -#include <altivec.h> +#include <rte_altivec.h> #include <rte_mbuf.h> #include <rte_mempool.h> diff --git a/drivers/net/mlx5/mlx5_utils.h b/drivers/net/mlx5/mlx5_utils.h index ebf79b8..fdf1379 100644 --- a/drivers/net/mlx5/mlx5_utils.h +++ b/drivers/net/mlx5/mlx5_utils.h @@ -15,16 +15,6 @@ #include "mlx5_defs.h" -/* - * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. std=c11. - * Otherwise there would be a type conflict between stdbool and altivec. - */ -#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__) -#undef bool -/* redefine as in stdbool.h */ -#define bool _Bool -#endif - /* Bit-field manipulation. */ #define BITFIELD_DECLARE(bf, type, size) \ type bf[(((size_t)(size) / (sizeof(type) * CHAR_BIT)) + \ diff --git a/drivers/net/virtio/virtio_rxtx_simple_altivec.c b/drivers/net/virtio/virtio_rxtx_simple_altivec.c index 47225f4..003b6ec 100644 --- a/drivers/net/virtio/virtio_rxtx_simple_altivec.c +++ b/drivers/net/virtio/virtio_rxtx_simple_altivec.c @@ -9,8 +9,7 @@ #include <string.h> #include <errno.h> -#include <altivec.h> - +#include <rte_altivec.h> #include <rte_byteorder.h> #include <rte_branch_prediction.h> #include <rte_cycles.h> diff --git a/lib/librte_eal/common/include/arch/ppc_64/meson.build b/lib/librte_eal/common/include/arch/ppc_64/meson.build index 00f9611..7949c86 100644 --- a/lib/librte_eal/common/include/arch/ppc_64/meson.build +++ b/lib/librte_eal/common/include/arch/ppc_64/meson.build @@ -2,6 +2,7 @@ # Copyright(c) 2018 Luca Boccassi <bluca@debian.org> install_headers( + 'rte_altivec.h', 'rte_atomic.h', 'rte_byteorder.h', 'rte_cpuflags.h', diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h index 02188e7..e63a121 100644 --- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h @@ -8,8 +8,8 @@ #include <stdint.h> #include <string.h> -/*To include altivec.h, GCC version must >= 4.8 */ -#include <altivec.h> + +#include "rte_altivec.h" #include "rte_common.h" diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h index 068c805..4caafd9 100644 --- a/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h +++ b/lib/librte_eal/common/include/arch/ppc_64/rte_vect.h @@ -6,7 +6,8 @@ #ifndef _RTE_VECT_PPC_64_H_ #define _RTE_VECT_PPC_64_H_ -#include <altivec.h> +#include "rte_altivec.h" + #include "generic/rte_vect.h" #ifdef __cplusplus diff --git a/lib/librte_eal/ppc/include/rte_altivec.h b/lib/librte_eal/ppc/include/rte_altivec.h new file mode 100644 index 0000000..1551a94 --- /dev/null +++ b/lib/librte_eal/ppc/include/rte_altivec.h @@ -0,0 +1,22 @@ +/* + * SPDX-License-Identifier: BSD-3-Clause + * Copyright (C) Mellanox 2020. + */ + +#ifndef _RTE_ALTIVEC_H_ +#define _RTE_ALTIVEC_H_ + +/* To include altivec.h, GCC version must be >= 4.8 */ +#include <altivec.h> + +/* + * Compilation workaround for PPC64 when AltiVec is fully enabled, e.g. std=c11. + * Otherwise there would be a type conflict between stdbool and altivec. + */ +#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__) +#undef bool +/* redefine as in stdbool.h */ +#define bool _Bool +#endif + +#endif /* _RTE_ALTIVEC_H_ */ -- 1.8.3.1
On Sun, 2020-05-31 at 15:36 +0000, Ori Kam wrote:
> [ upstream commit f5bf02df3145f95b1ee8ed9dee67f4222ac42c8c ]
>
> 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
This patch breaks all ppc64 builds:
[ 136s] In file included from /home/abuild/rpmbuild/BUILD/dpdk-1591003733.2dff15dd5/lib/librte_eal/common/eal_common_options.c:27:
[ 136s] /home/abuild/rpmbuild/BUILD/dpdk-1591003733.2dff15dd5/ppc_64-power8-linux-gcc/include/rte_memcpy.h:12:10: fatal error: rte_altivec.h: No such file or directory
[ 136s] #include "rte_altivec.h"
--
Kind regards,
Luca Boccassi
Hi Luca,
Off list.
Can you please see that the rte_altivec.h file was added?
I don't have a setup with ppc.
Thanks,
Ori
> -----Original Message-----
> From: Luca Boccassi <bluca@debian.org>
> Sent: Monday, June 1, 2020 1:07 PM
> To: Ori Kam <orika@mellanox.com>; David Christensen
> <drc@linux.vnet.ibm.com>; Beilei Xing <beilei.xing@intel.com>; Qi Zhang
> <qi.z.zhang@intel.com>; Matan Azrad <matan@mellanox.com>; Shahaf Shuler
> <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> Maxime Coquelin <maxime.coquelin@redhat.com>; Tiwei Bie
> <tiwei.bie@intel.com>; Zhihong Wang <zhihong.wang@intel.com>
> Cc: stable@dpdk.org
> Subject: Re: [PATCH 19.11] eal/ppc: fix bool type after altivec include
>
> On Sun, 2020-05-31 at 15:36 +0000, Ori Kam wrote:
> > [ upstream commit f5bf02df3145f95b1ee8ed9dee67f4222ac42c8c ]
> >
> > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dpd
> k.org%2Farchives%2Fdev%2F2018-
> August%2F110281.html&data=02%7C01%7Corika%40mellanox.com%7C30
> f4a48b032b46dbb97408d8061390af%7Ca652971c7d2e4d9ba6a4d149256f461b
> %7C0%7C0%7C637266028392843046&sdata=fJAaZN9tNjycMH30Gwh8ILZ
> %2FjuiYgBVN%2BwdAn6GAbcY%3D&reserved=0
>
> This patch breaks all ppc64 builds:
>
> [ 136s] In file included from /home/abuild/rpmbuild/BUILD/dpdk-
> 1591003733.2dff15dd5/lib/librte_eal/common/eal_common_options.c:27:
> [ 136s] /home/abuild/rpmbuild/BUILD/dpdk-1591003733.2dff15dd5/ppc_64-
> power8-linux-gcc/include/rte_memcpy.h:12:10: fatal error: rte_altivec.h: No
> such file or directory
> [ 136s] #include "rte_altivec.h"
>
> --
> Kind regards,
> Luca Boccassi
Hi,
Yes, it's part of your patch. Probably some build files machinery
missing. I do not have a ppc setup either.
On Tue, 2020-06-02 at 11:27 +0000, Ori Kam wrote:
> Hi Luca,
> Off list.
>
> Can you please see that the rte_altivec.h file was added?
> I don't have a setup with ppc.
>
> Thanks,
> Ori
>
>
> > -----Original Message-----
> > From: Luca Boccassi <bluca@debian.org>
> > Sent: Monday, June 1, 2020 1:07 PM
> > To: Ori Kam <orika@mellanox.com>; David Christensen
> > <drc@linux.vnet.ibm.com>; Beilei Xing <beilei.xing@intel.com>; Qi Zhang
> > <qi.z.zhang@intel.com>; Matan Azrad <matan@mellanox.com>; Shahaf Shuler
> > <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> > Maxime Coquelin <maxime.coquelin@redhat.com>; Tiwei Bie
> > <tiwei.bie@intel.com>; Zhihong Wang <zhihong.wang@intel.com>
> > Cc: stable@dpdk.org
> > Subject: Re: [PATCH 19.11] eal/ppc: fix bool type after altivec include
> >
> > On Sun, 2020-05-31 at 15:36 +0000, Ori Kam wrote:
> > > [ upstream commit f5bf02df3145f95b1ee8ed9dee67f4222ac42c8c ]
> > >
> > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dpd
> > k.org%2Farchives%2Fdev%2F2018-
> > August%2F110281.html&data=02%7C01%7Corika%40mellanox.com%7C30
> > f4a48b032b46dbb97408d8061390af%7Ca652971c7d2e4d9ba6a4d149256f461b
> > %7C0%7C0%7C637266028392843046&sdata=fJAaZN9tNjycMH30Gwh8ILZ
> > %2FjuiYgBVN%2BwdAn6GAbcY%3D&reserved=0
> >
> > This patch breaks all ppc64 builds:
> >
> > [ 136s] In file included from /home/abuild/rpmbuild/BUILD/dpdk-
> > 1591003733.2dff15dd5/lib/librte_eal/common/eal_common_options.c:27:
> > [ 136s] /home/abuild/rpmbuild/BUILD/dpdk-1591003733.2dff15dd5/ppc_64-
> > power8-linux-gcc/include/rte_memcpy.h:12:10: fatal error: rte_altivec.h: No
> > such file or directory
> > [ 136s] #include "rte_altivec.h"
> >
> > --
> > Kind regards,
> > Luca Boccassi
Do you need anything else from me?
Thanks,
Ori
> -----Original Message-----
> From: Luca Boccassi <bluca@debian.org>
> Sent: Tuesday, June 2, 2020 4:30 PM
> To: Ori Kam <orika@mellanox.com>
> Cc: stable@dpdk.org
> Subject: Re: [dpdk-stable] [PATCH 19.11] eal/ppc: fix bool type after altivec
> include
>
> Hi,
>
> Yes, it's part of your patch. Probably some build files machinery
> missing. I do not have a ppc setup either.
>
> On Tue, 2020-06-02 at 11:27 +0000, Ori Kam wrote:
> > Hi Luca,
> > Off list.
> >
> > Can you please see that the rte_altivec.h file was added?
> > I don't have a setup with ppc.
> >
> > Thanks,
> > Ori
> >
> >
> > > -----Original Message-----
> > > From: Luca Boccassi <bluca@debian.org>
> > > Sent: Monday, June 1, 2020 1:07 PM
> > > To: Ori Kam <orika@mellanox.com>; David Christensen
> > > <drc@linux.vnet.ibm.com>; Beilei Xing <beilei.xing@intel.com>; Qi Zhang
> > > <qi.z.zhang@intel.com>; Matan Azrad <matan@mellanox.com>; Shahaf
> Shuler
> > > <shahafs@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> > > Maxime Coquelin <maxime.coquelin@redhat.com>; Tiwei Bie
> > > <tiwei.bie@intel.com>; Zhihong Wang <zhihong.wang@intel.com>
> > > Cc: stable@dpdk.org
> > > Subject: Re: [PATCH 19.11] eal/ppc: fix bool type after altivec include
> > >
> > > On Sun, 2020-05-31 at 15:36 +0000, Ori Kam wrote:
> > > > [ upstream commit f5bf02df3145f95b1ee8ed9dee67f4222ac42c8c ]
> > > >
> > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dpd
> > > k.org%2Farchives%2Fdev%2F2018-
> > >
> August%2F110281.html&data=02%7C01%7Corika%40mellanox.com%7C30
> > >
> f4a48b032b46dbb97408d8061390af%7Ca652971c7d2e4d9ba6a4d149256f461b
> > >
> %7C0%7C0%7C637266028392843046&sdata=fJAaZN9tNjycMH30Gwh8ILZ
> > > %2FjuiYgBVN%2BwdAn6GAbcY%3D&reserved=0
> > >
> > > This patch breaks all ppc64 builds:
> > >
> > > [ 136s] In file included from /home/abuild/rpmbuild/BUILD/dpdk-
> > > 1591003733.2dff15dd5/lib/librte_eal/common/eal_common_options.c:27:
> > > [ 136s] /home/abuild/rpmbuild/BUILD/dpdk-
> 1591003733.2dff15dd5/ppc_64-
> > > power8-linux-gcc/include/rte_memcpy.h:12:10: fatal error: rte_altivec.h:
> No
> > > such file or directory
> > > [ 136s] #include "rte_altivec.h"
> > >
> > > --
> > > Kind regards,
> > > Luca Boccassi
Ori, Luca,
On Sun, May 31, 2020 at 5:36 PM Ori Kam <orika@mellanox.com> wrote:
> create mode 100644 lib/librte_eal/ppc/include/rte_altivec.h
It should be lib/librte_eal/common/include/arch/ppc_64/rte_altivec.h in 19.11.
--
David Marchand
On Tue, 2020-06-02 at 16:25 +0200, David Marchand wrote:
> Ori, Luca,
>
> On Sun, May 31, 2020 at 5:36 PM Ori Kam <orika@mellanox.com> wrote:
> > create mode 100644 lib/librte_eal/ppc/include/rte_altivec.h
>
> It should be lib/librte_eal/common/include/arch/ppc_64/rte_altivec.h in 19.11.
Thanks, this works.
--
Kind regards,
Luca Boccassi