ppc64: fix compilation of when AltiVec is enabled
Checks
Commit Message
The definition of almost any newer standard like --stc=c11 will drop
__APPLCE_ALTIVEC__ which otherwise would be defined.
If that is the case then altivec.h will redefine bool to a type
conflicting with those defined by stdbool.h.
This breaks compilation of 18.08 on ppc64 like:
mlx5_nl_flow.c:407:17: error: incompatible types when assigning to type
‘__vector __bool int’ {aka ‘__vector(4) __bool int’} from type ‘int’
in_port_id_set = false;
Other alternatives were pursued on [1] but they always ended up being more
complex than what would be appropriate for the issue we face.
[1]: http://mails.dpdk.org/archives/dev/2018-August/109926.html
Change-Id: I1ed56da954e4951b9d120ca2ac0c0c218b4a0140
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
---
.../common/include/arch/ppc_64/rte_memcpy.h | 11 +++++++++++
1 file changed, 11 insertions(+)
Comments
>宛先: adrien.mazarguil@6wind.com, dev <dev@dpdk.org>, Gowrishankar
>Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>, Chao Zhu
><chaozhu@linux.vnet.ibm.com>
>送信元: Christian Ehrhardt
>送信者: "dev"
>日付: 2018/08/30 07:00PM
>Cc: Luca Boccassi <bluca@debian.org>, Thomas Monjalon
><thomasm@mellanox.com>, Christian Ehrhardt
><christian.ehrhardt@canonical.com>
>件名: [dpdk-dev] [PATCH] ppc64: fix compilation of when AltiVec is
>enabled
>
>The definition of almost any newer standard like --stc=c11 will drop
>__APPLCE_ALTIVEC__ which otherwise would be defined.
>If that is the case then altivec.h will redefine bool to a type
>conflicting with those defined by stdbool.h.
>
>This breaks compilation of 18.08 on ppc64 like:
> mlx5_nl_flow.c:407:17: error: incompatible types when assigning to
>type
> ‘__vector __bool int’ {aka ‘__vector(4) __bool int’} from type
>‘int’
> in_port_id_set = false;
>
>Other alternatives were pursued on [1] but they always ended up being
>more
>complex than what would be appropriate for the issue we face.
>
>[1]:
>INVALID URI REMOVED
>chives_dev_2018-2DAugust_109926.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZO
>g&r=EZR6Jx10q0q3dTopeH3WIQ&m=bbU1KVc1ZvNW9Rz7B0MLHfS0f0oZv35d2mpRpHO0
>ByY&s=RvMIFfk-cAAGTrYM76-iSSqIYV_X2EptYZzYIweIHRk&e=
>
>Change-Id: I1ed56da954e4951b9d120ca2ac0c0c218b4a0140
>Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
>---
> .../common/include/arch/ppc_64/rte_memcpy.h | 11
>+++++++++++
> 1 file changed, 11 insertions(+)
>
>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 75f74897b..0b3b89b56 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
>@@ -37,6 +37,17 @@
> #include <string.h>
> /*To include altivec.h, GCC version must >= 4.8 */
> #include <altivec.h>
>+/*
>+ * Compilation workaround for PPC64 targets when AltiVec is fully
>+ * enabled e.g. with std=c11. Otherwise there would be a type
>conflict
>+ * of "bool" between stdbool and altivec.
>+ */
>+#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
>+ #undef bool
>+ /* redefine as in stdbool.h */
>+ #define bool _Bool
>+#endif
>+
>
> #ifdef __cplusplus
> extern "C" {
>--
>2.17.1
>
>
>
Hi,
I could reproduce the issue you reported in 18.08 with my ppc64le box with RedHat 7.5 and GCC4.8.
The patch resolved the issue in my environment. Thanks!
I am a bit newbie in dpdk-dev, but I will try contacting Chao and other IBM guys... Sorry for our slow reply.
Regards,
Takeshi
On Thu, Aug 30, 2018 at 12:52 PM Takeshi T Yoshimura <TYOS@jp.ibm.com>
wrote:
> >宛先: adrien.mazarguil@6wind.com, dev <dev@dpdk.org>, Gowrishankar
> >Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>, Chao Zhu
> ><chaozhu@linux.vnet.ibm.com>
> >送信元: Christian Ehrhardt
> >送信者: "dev"
> >日付: 2018/08/30 07:00PM
> >Cc: Luca Boccassi <bluca@debian.org>, Thomas Monjalon
> ><thomasm@mellanox.com>, Christian Ehrhardt
> ><christian.ehrhardt@canonical.com>
> >件名: [dpdk-dev] [PATCH] ppc64: fix compilation of when AltiVec is
> >enabled
> >
> >The definition of almost any newer standard like --stc=c11 will drop
> >__APPLCE_ALTIVEC__ which otherwise would be defined.
> >If that is the case then altivec.h will redefine bool to a type
> >conflicting with those defined by stdbool.h.
> >
> >This breaks compilation of 18.08 on ppc64 like:
> > mlx5_nl_flow.c:407:17: error: incompatible types when assigning to
> >type
> > ‘__vector __bool int’ {aka ‘__vector(4) __bool int’} from type
> >‘int’
> > in_port_id_set = false;
> >
> >Other alternatives were pursued on [1] but they always ended up being
> >more
> >complex than what would be appropriate for the issue we face.
> >
> >[1]:
> >INVALID URI REMOVED
> >chives_dev_2018-2DAugust_109926.html&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZO
> >g&r=EZR6Jx10q0q3dTopeH3WIQ&m=bbU1KVc1ZvNW9Rz7B0MLHfS0f0oZv35d2mpRpHO0
> >ByY&s=RvMIFfk-cAAGTrYM76-iSSqIYV_X2EptYZzYIweIHRk&e=
> >
> >Change-Id: I1ed56da954e4951b9d120ca2ac0c0c218b4a0140
> >Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> >---
> > .../common/include/arch/ppc_64/rte_memcpy.h | 11
> >+++++++++++
> > 1 file changed, 11 insertions(+)
> >
> >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 75f74897b..0b3b89b56 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
> >@@ -37,6 +37,17 @@
> > #include <string.h>
> > /*To include altivec.h, GCC version must >= 4.8 */
> > #include <altivec.h>
> >+/*
> >+ * Compilation workaround for PPC64 targets when AltiVec is fully
> >+ * enabled e.g. with std=c11. Otherwise there would be a type
> >conflict
> >+ * of "bool" between stdbool and altivec.
> >+ */
> >+#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
> >+ #undef bool
> >+ /* redefine as in stdbool.h */
> >+ #define bool _Bool
> >+#endif
> >+
> >
> > #ifdef __cplusplus
> > extern "C" {
> >--
> >2.17.1
> >
> >
> >
>
> Hi,
> I could reproduce the issue you reported in 18.08 with my ppc64le box with
> RedHat 7.5 and GCC4.8.
> The patch resolved the issue in my environment. Thanks!
>
I added your test (tanks) and Adrien's extensive review/discussion as tags
and also addressed a few checkpatch findings.
V2 is up on the list now ...
> I am a bit newbie in dpdk-dev, but I will try contacting Chao and other
> IBM guys... Sorry for our slow reply.
>
Thanks for your participation Takeshi,
we at least now have had a few replies after Thomas used the superpowers of
"CPT. CAPSLOCK" \o/.
I also have a call later today to make sure this is brought up inside IBM
to make sure someone is maintaining it for real.
> Regards,
> Takeshi
>
>
Hi,
30/08/2018 13:58, Christian Ehrhardt:
> On Thu, Aug 30, 2018 at 12:52 PM Takeshi T Yoshimura <TYOS@jp.ibm.com>
> wrote:
> > Hi,
> > I could reproduce the issue you reported in 18.08 with my ppc64le box with
> > RedHat 7.5 and GCC4.8.
> > The patch resolved the issue in my environment. Thanks!
>
> I added your test (tanks) and Adrien's extensive review/discussion as tags
> and also addressed a few checkpatch findings.
> V2 is up on the list now ...
>
> > I am a bit newbie in dpdk-dev, but I will try contacting Chao and other
> > IBM guys... Sorry for our slow reply.
>
> Thanks for your participation Takeshi,
> we at least now have had a few replies after Thomas used the superpowers of
> "CPT. CAPSLOCK" \o/.
>
> I also have a call later today to make sure this is brought up inside IBM
> to make sure someone is maintaining it for real.
Summary of the situation:
- I used caps lock on August 30th
- We got replies on the ML in the next 2 days (Alfredo, Chao, Takeshi)
- On September 3rd, Adrien raised a major issue for C++ with the fix v3
http://mails.dpdk.org/archives/dev/2018-September/110733.html
- Another email about a possible GCC fix on September 5th (David Wilder)
- There was a private reply on September 27th, confirming an IBM support
- and nothing else
Nobody at IBM requests to get a compilation fix for ppc64.
And there was no issue raised after 18.11-rc1 release.
I guess it means DPDK is not used on ppc64.
In this case, we should mark the ppc port as unmaintained for 18.11.
OR SHOULD I USE MY CAPS LOCK AGAIN?
Thomas Monjalon <thomas@monjalon.net> wrote on 11/05/2018 06:15:53 AM:
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Christian Ehrhardt <christian.ehrhardt@canonical.com>
> Cc: dev@dpdk.org, TYOS@jp.ibm.com, adrien.mazarguil@6wind.com,
> Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>, Chao
> Zhu <chaozhu@linux.vnet.ibm.com>, Luca Boccassi <bluca@debian.org>,
> Pradeep Satyanarayana <pradeep@us.ibm.com>, dwilder@us.ibm.com
> Date: 11/05/2018 06:16 AM
> Subject: Re: [dpdk-dev] [PATCH] ppc64: fix compilation of when
> AltiVec is enabled
>
> Hi,
>
> 30/08/2018 13:58, Christian Ehrhardt:
> > On Thu, Aug 30, 2018 at 12:52 PM Takeshi T Yoshimura <TYOS@jp.ibm.com>
> > wrote:
> > > Hi,
> > > I could reproduce the issue you reported in 18.08 with my ppc64le box
with
> > > RedHat 7.5 and GCC4.8.
> > > The patch resolved the issue in my environment. Thanks!
> >
> > I added your test (tanks) and Adrien's extensive review/discussion as
tags
> > and also addressed a few checkpatch findings.
> > V2 is up on the list now ...
> >
> > > I am a bit newbie in dpdk-dev, but I will try contacting Chao and
other
> > > IBM guys... Sorry for our slow reply.
> >
> > Thanks for your participation Takeshi,
> > we at least now have had a few replies after Thomas used the
superpowers of
> > "CPT. CAPSLOCK" \o/.
> >
> > I also have a call later today to make sure this is brought up inside
IBM
> > to make sure someone is maintaining it for real.
>
> Summary of the situation:
> - I used caps lock on August 30th
> - We got replies on the ML in the next 2 days (Alfredo, Chao, Takeshi)
> - On September 3rd, Adrien raised a major issue for C++ with the fix
v3
> INVALID URI REMOVED
>
u=http-3A__mails.dpdk.org_archives_dev_2018-2DSeptember_110733.html&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=co4lCofxrQP11yIVMply-
>
QYvsUyeKJkYY_jL1QVgeGA&m=dMrH4GLoXWGcc5xt87goaWszBzO4TeTVx7O9pZo160o&s=_hNc10YMFL2mf2TkG9tbjm5_2fyPER3MswvK-
> NKs9RY&e=
> - Another email about a possible GCC fix on September 5th (David
Wilder)
As Dave mentioned that is only expected in GCC 9.
> - There was a private reply on September 27th, confirming an IBM
support
> - and nothing else
>
> Nobody at IBM requests to get a compilation fix for ppc64.
Yes, we do need fixes for ppc64.
(1) http://mails.dpdk.org/archives/dev/2018-August/110499.html
(2) http://mails.dpdk.org/archives/dev/2018-September/110961.html
Based on the above 2 URLs (tested both by Takeshi and David Wiler), we
assumed that it would get
picked up in 18.11. We have been more focussed on 17.11 (and likely dropped
the ball on 18.11)
since 17.11 is an LTS release and we have had lots of problems on ppc64.
Should be submitting
patch to fix those issues shortly.
We have built 18.11-rc1 with the fix above (1), and it does work on
ppc64le.
An updated version of:
(3) http://mails.dpdk.org/archives/dev/2018-August/109926.html
also builds on ppc64. The latter has the advantage of possibly not
breaking existing applications.
> And there was no issue raised after 18.11-rc1 release.
> I guess it means DPDK is not used on ppc64.
> In this case, we should mark the ppc port as unmaintained for 18.11.
>
> OR SHOULD I USE MY CAPS LOCK AGAIN?
Thanks for your patience while we iron out the issues. Hopefully, we don't
need the CAPS LOCK again.
Thanks
Pradeep
pradeep@us.ibm.com
05/11/2018 22:20, Pradeep Satyanarayana:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 30/08/2018 13:58, Christian Ehrhardt:
> > > On Thu, Aug 30, 2018 Takeshi T Yoshimura <TYOS@jp.ibm.com> wrote:
> > > > Hi,
> > > > I could reproduce the issue you reported in 18.08 with my ppc64le
> > > > box with RedHat 7.5 and GCC4.8.
> > > > The patch resolved the issue in my environment. Thanks!
> > >
> > > I added your test (tanks) and Adrien's extensive review/discussion as
> > > tags and also addressed a few checkpatch findings.
> > > V2 is up on the list now ...
> > >
> > > > I am a bit newbie in dpdk-dev, but I will try contacting Chao
> > > > and other IBM guys... Sorry for our slow reply.
> > >
> > > Thanks for your participation Takeshi,
> > > we at least now have had a few replies after Thomas used the
> > > superpowers of "CPT. CAPSLOCK" \o/.
> > >
> > > I also have a call later today to make sure this is brought up
> > > inside IBM to make sure someone is maintaining it for real.
> >
> > Summary of the situation:
> > - I used caps lock on August 30th
> > - We got replies on the ML in the next 2 days (Alfredo, Chao, Takeshi)
> > - On September 3rd, Adrien raised a major issue for C++ with the fix v3
> > http://mails.dpdk.org/archives/dev/2018-September/110733.html
> > - Another email about a possible GCC fix on September 5th (David Wilder)
>
> As Dave mentioned that is only expected in GCC 9.
>
> > - There was a private reply on September 27th, confirming an IBM support
> > - and nothing else
> >
> > Nobody at IBM requests to get a compilation fix for ppc64.
>
> Yes, we do need fixes for ppc64.
>
> (1) http://mails.dpdk.org/archives/dev/2018-August/110499.html
> (2) http://mails.dpdk.org/archives/dev/2018-September/110961.html
>
> Based on the above 2 URLs (tested both by Takeshi and David Wiler), we
> assumed that it would get picked up in 18.11.
> We have been more focussed on 17.11 (and likely dropped
> the ball on 18.11)
> since 17.11 is an LTS release and we have had lots of problems on ppc64.
Note that 18.11 is also LTS.
> Should be submitting patch to fix those issues shortly.
Sorry, I have some doubts for two reasons:
- track records
- technical reality: there is no perfect solution outside of GCC
> We have built 18.11-rc1 with the fix above (1), and it does work on
> ppc64le.
But it would break C++ applications.
> An updated version of:
>
> (3) http://mails.dpdk.org/archives/dev/2018-August/109926.html
>
> also builds on ppc64. The latter has the advantage of possibly not
> breaking existing applications.
But it fixes only mlx5.
stdbool is used in many other places.
Which PMDs are you compiling?
Are you compiling examples?
> > And there was no issue raised after 18.11-rc1 release.
> > I guess it means DPDK is not used on ppc64.
> > In this case, we should mark the ppc port as unmaintained for 18.11.
> >
> > OR SHOULD I USE MY CAPS LOCK AGAIN?
>
> Thanks for your patience while we iron out the issues.
> Hopefully, we don't need the CAPS LOCK again.
We have to mention the ppc64 incompatibility in 18.11 release notes.
Either it stays as is and we declare DPDK 18.11 not supported on
IBM platforms, or we fix it and document the limitations.
On 2018-11-07 02:03, Thomas Monjalon wrote:
> 05/11/2018 22:20, Pradeep Satyanarayana:
>> From: Thomas Monjalon <thomas@monjalon.net>
>> > 30/08/2018 13:58, Christian Ehrhardt:
>> > > On Thu, Aug 30, 2018 Takeshi T Yoshimura <TYOS@jp.ibm.com> wrote:
>> > > > Hi,
>> > > > I could reproduce the issue you reported in 18.08 with my ppc64le
>> > > > box with RedHat 7.5 and GCC4.8.
>> > > > The patch resolved the issue in my environment. Thanks!
>> > >
>> > > I added your test (tanks) and Adrien's extensive review/discussion as
>> > > tags and also addressed a few checkpatch findings.
>> > > V2 is up on the list now ...
>> > >
>> > > > I am a bit newbie in dpdk-dev, but I will try contacting Chao
>> > > > and other IBM guys... Sorry for our slow reply.
>> > >
>> > > Thanks for your participation Takeshi,
>> > > we at least now have had a few replies after Thomas used the
>> > > superpowers of "CPT. CAPSLOCK" \o/.
>> > >
>> > > I also have a call later today to make sure this is brought up
>> > > inside IBM to make sure someone is maintaining it for real.
>> >
>> > Summary of the situation:
>> > - I used caps lock on August 30th
>> > - We got replies on the ML in the next 2 days (Alfredo, Chao, Takeshi)
>> > - On September 3rd, Adrien raised a major issue for C++ with the fix v3
>> > http://mails.dpdk.org/archives/dev/2018-September/110733.html
>> > - Another email about a possible GCC fix on September 5th (David Wilder)
>>
>> As Dave mentioned that is only expected in GCC 9.
>>
>> > - There was a private reply on September 27th, confirming an IBM support
>> > - and nothing else
>> >
>> > Nobody at IBM requests to get a compilation fix for ppc64.
>>
>> Yes, we do need fixes for ppc64.
>>
>> (1)
>> http://mails.dpdk.org/archives/dev/2018-August/110499.html
>> (2)
>> http://mails.dpdk.org/archives/dev/2018-September/110961.html
>>
>> Based on the above 2 URLs (tested both by Takeshi and David Wiler), we
>> assumed that it would get picked up in 18.11.
>> We have been more focussed on 17.11 (and likely dropped
>> the ball on 18.11)
>> since 17.11 is an LTS release and we have had lots of problems on
>> ppc64.
>
> Note that 18.11 is also LTS.
>
>> Should be submitting patch to fix those issues shortly.
>
> Sorry, I have some doubts for two reasons:
> - track records
> - technical reality: there is no perfect solution outside of GCC
>
>> We have built 18.11-rc1 with the fix above (1), and it does work on
>> ppc64le.
>
> But it would break C++ applications.
>
>> An updated version of:
>>
>> (3)
>> http://mails.dpdk.org/archives/dev/2018-August/109926.html
>>
>> also builds on ppc64. The latter has the advantage of possibly not
>> breaking existing applications.
>
I am not seeing any build breaks on upstream code with the
net-mlx5-fix-build-on-PPC64.patch applied.
> But it fixes only mlx5.
> stdbool is used in many other places.
> Which PMDs are you compiling?
CONFIG_RTE_LIBRTE_ARK_PMD=y
CONFIG_RTE_LIBRTE_AXGBE_PMD=y
CONFIG_RTE_LIBRTE_BNXT_PMD=y
CONFIG_RTE_LIBRTE_CXGBE_PMD=y
CONFIG_RTE_LIBRTE_DPAA_PMD=y
CONFIG_RTE_LIBRTE_DPAA2_PMD=y
CONFIG_RTE_LIBRTE_ENETC_PMD=y
CONFIG_RTE_LIBRTE_ENA_PMD=y
CONFIG_RTE_LIBRTE_EM_PMD=y
CONFIG_RTE_LIBRTE_IGB_PMD=y
CONFIG_RTE_LIBRTE_I40E_PMD=y
CONFIG_RTE_LIBRTE_AVF_PMD=y
CONFIG_RTE_LIBRTE_MLX5_PMD=y
CONFIG_RTE_LIBRTE_NFP_PMD=y
CONFIG_RTE_LIBRTE_QEDE_PMD=y
CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD=y
CONFIG_RTE_LIBRTE_LIO_PMD=y
CONFIG_RTE_LIBRTE_OCTEONTX_PMD=y
CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
CONFIG_RTE_LIBRTE_NETVSC_PMD=y
CONFIG_RTE_LIBRTE_VDEV_NETVSC_PMD=y
CONFIG_RTE_LIBRTE_IFC_PMD=y
CONFIG_RTE_TEST_PMD=y
> Are you compiling examples?
Yes, no build issues seen.
>
>> > And there was no issue raised after 18.11-rc1 release.
>> > I guess it means DPDK is not used on ppc64.
>> > In this case, we should mark the ppc port as unmaintained for 18.11.
>> >
>> > OR SHOULD I USE MY CAPS LOCK AGAIN?
>>
>> Thanks for your patience while we iron out the issues.
>> Hopefully, we don't need the CAPS LOCK again.
>
> We have to mention the ppc64 incompatibility in 18.11 release notes.
> Either it stays as is and we declare DPDK 18.11 not supported on
> IBM platforms, or we fix it and document the limitations.
If net-mlx5-fix-build-on-PPC64.patch is accepted I feel power can be
listed as supported for 18.11.
07/11/2018 19:58, dwilder:
> On 2018-11-07 02:03, Thomas Monjalon wrote:
> > 05/11/2018 22:20, Pradeep Satyanarayana:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >> > 30/08/2018 13:58, Christian Ehrhardt:
> >> > > On Thu, Aug 30, 2018 Takeshi T Yoshimura <TYOS@jp.ibm.com> wrote:
> >> > > > Hi,
> >> > > > I could reproduce the issue you reported in 18.08 with my ppc64le
> >> > > > box with RedHat 7.5 and GCC4.8.
> >> > > > The patch resolved the issue in my environment. Thanks!
> >> > >
> >> > > I added your test (tanks) and Adrien's extensive review/discussion as
> >> > > tags and also addressed a few checkpatch findings.
> >> > > V2 is up on the list now ...
> >> > >
> >> > > > I am a bit newbie in dpdk-dev, but I will try contacting Chao
> >> > > > and other IBM guys... Sorry for our slow reply.
> >> > >
> >> > > Thanks for your participation Takeshi,
> >> > > we at least now have had a few replies after Thomas used the
> >> > > superpowers of "CPT. CAPSLOCK" \o/.
> >> > >
> >> > > I also have a call later today to make sure this is brought up
> >> > > inside IBM to make sure someone is maintaining it for real.
> >> >
> >> > Summary of the situation:
> >> > - I used caps lock on August 30th
> >> > - We got replies on the ML in the next 2 days (Alfredo, Chao, Takeshi)
> >> > - On September 3rd, Adrien raised a major issue for C++ with the fix v3
> >> > http://mails.dpdk.org/archives/dev/2018-September/110733.html
> >> > - Another email about a possible GCC fix on September 5th (David Wilder)
> >>
> >> As Dave mentioned that is only expected in GCC 9.
> >>
> >> > - There was a private reply on September 27th, confirming an IBM support
> >> > - and nothing else
> >> >
> >> > Nobody at IBM requests to get a compilation fix for ppc64.
> >>
> >> Yes, we do need fixes for ppc64.
> >>
> >> (1)
> >> http://mails.dpdk.org/archives/dev/2018-August/110499.html
> >> (2)
> >> http://mails.dpdk.org/archives/dev/2018-September/110961.html
> >>
> >> Based on the above 2 URLs (tested both by Takeshi and David Wiler), we
> >> assumed that it would get picked up in 18.11.
> >> We have been more focussed on 17.11 (and likely dropped
> >> the ball on 18.11)
> >> since 17.11 is an LTS release and we have had lots of problems on
> >> ppc64.
> >
> > Note that 18.11 is also LTS.
> >
> >> Should be submitting patch to fix those issues shortly.
> >
> > Sorry, I have some doubts for two reasons:
> > - track records
> > - technical reality: there is no perfect solution outside of GCC
> >
> >> We have built 18.11-rc1 with the fix above (1), and it does work on
> >> ppc64le.
> >
> > But it would break C++ applications.
> >
> >> An updated version of:
> >>
> >> (3)
> >> http://mails.dpdk.org/archives/dev/2018-August/109926.html
> >>
> >> also builds on ppc64. The latter has the advantage of possibly not
> >> breaking existing applications.
>
> I am not seeing any build breaks on upstream code with the
> net-mlx5-fix-build-on-PPC64.patch applied.
>
> > But it fixes only mlx5.
> > stdbool is used in many other places.
> > Which PMDs are you compiling?
>
> CONFIG_RTE_LIBRTE_ARK_PMD=y
> CONFIG_RTE_LIBRTE_AXGBE_PMD=y
> CONFIG_RTE_LIBRTE_BNXT_PMD=y
> CONFIG_RTE_LIBRTE_CXGBE_PMD=y
> CONFIG_RTE_LIBRTE_DPAA_PMD=y
> CONFIG_RTE_LIBRTE_DPAA2_PMD=y
> CONFIG_RTE_LIBRTE_ENETC_PMD=y
> CONFIG_RTE_LIBRTE_ENA_PMD=y
> CONFIG_RTE_LIBRTE_EM_PMD=y
> CONFIG_RTE_LIBRTE_IGB_PMD=y
> CONFIG_RTE_LIBRTE_I40E_PMD=y
> CONFIG_RTE_LIBRTE_AVF_PMD=y
> CONFIG_RTE_LIBRTE_MLX5_PMD=y
> CONFIG_RTE_LIBRTE_NFP_PMD=y
> CONFIG_RTE_LIBRTE_QEDE_PMD=y
> CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD=y
> CONFIG_RTE_LIBRTE_LIO_PMD=y
> CONFIG_RTE_LIBRTE_OCTEONTX_PMD=y
> CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
> CONFIG_RTE_LIBRTE_NETVSC_PMD=y
> CONFIG_RTE_LIBRTE_VDEV_NETVSC_PMD=y
> CONFIG_RTE_LIBRTE_IFC_PMD=y
> CONFIG_RTE_TEST_PMD=y
>
> > Are you compiling examples?
>
> Yes, no build issues seen.
>
> >> > And there was no issue raised after 18.11-rc1 release.
> >> > I guess it means DPDK is not used on ppc64.
> >> > In this case, we should mark the ppc port as unmaintained for 18.11.
> >> >
> >> > OR SHOULD I USE MY CAPS LOCK AGAIN?
> >>
> >> Thanks for your patience while we iron out the issues.
> >> Hopefully, we don't need the CAPS LOCK again.
> >
> > We have to mention the ppc64 incompatibility in 18.11 release notes.
> > Either it stays as is and we declare DPDK 18.11 not supported on
> > IBM platforms, or we fix it and document the limitations.
>
> If net-mlx5-fix-build-on-PPC64.patch is accepted I feel power can be
> listed as supported for 18.11.
I sent this last patch which was thought by Christian (Canonical) and
Adrien (6WIND). It is just fixing the compilation.
Is there someone at IBM checking that basic DPDK features are working?
Thomas Monjalon <thomas@monjalon.net> wrote on 11/07/2018 01:21:22 PM:
> From: Thomas Monjalon <thomas@monjalon.net>
> To: dwilder <dwilder@us.ibm.com>
> Cc: Pradeep Satyanarayana <pradeep@us.ibm.com>, dev@dpdk.org,
> adrien.mazarguil@6wind.com, Luca Boccassi <bluca@debian.org>, Chao
> Zhu <chaozhu@linux.vnet.ibm.com>, Christian Ehrhardt
> <christian.ehrhardt@canonical.com>, TYOS@jp.ibm.com
> Date: 11/07/2018 01:21 PM
> Subject: Re: [dpdk-dev] [PATCH] ppc64: fix compilation of when
> AltiVec is enabled
>
> 07/11/2018 19:58, dwilder:
> > On 2018-11-07 02:03, Thomas Monjalon wrote:
> > > 05/11/2018 22:20, Pradeep Satyanarayana:
> > >> From: Thomas Monjalon <thomas@monjalon.net>
> > >> > 30/08/2018 13:58, Christian Ehrhardt:
> > >> > > On Thu, Aug 30, 2018 Takeshi T Yoshimura <TYOS@jp.ibm.com>
wrote:
> > >> > > > Hi,
> > >> > > > I could reproduce the issue you reported in 18.08 with my
ppc64le
> > >> > > > box with RedHat 7.5 and GCC4.8.
> > >> > > > The patch resolved the issue in my environment. Thanks!
> > >> > >
> > >> > > I added your test (tanks) and Adrien's extensive
review/discussion as
> > >> > > tags and also addressed a few checkpatch findings.
> > >> > > V2 is up on the list now ...
> > >> > >
> > >> > > > I am a bit newbie in dpdk-dev, but I will try contacting Chao
> > >> > > > and other IBM guys... Sorry for our slow reply.
> > >> > >
> > >> > > Thanks for your participation Takeshi,
> > >> > > we at least now have had a few replies after Thomas used the
> > >> > > superpowers of "CPT. CAPSLOCK" \o/.
> > >> > >
> > >> > > I also have a call later today to make sure this is brought up
> > >> > > inside IBM to make sure someone is maintaining it for real.
> > >> >
> > >> > Summary of the situation:
> > >> > - I used caps lock on August 30th
> > >> > - We got replies on the ML in the next 2 days (Alfredo,
> Chao, Takeshi)
> > >> > - On September 3rd, Adrien raised a major issue for C++
> with the fix v3
> > >> > INVALID URI REMOVED
>
u=http-3A__mails.dpdk.org_archives_dev_2018-2DSeptember_110733.html&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=co4lCofxrQP11yIVMply-QYvsUyeKJkYY_jL1QVgeGA&m=QE2-
> XfLmWX5fRwewYIIMAHJI_FETkneZA1XxK2aFv0o&s=DuOB1QOoJ-fW2A-0h6Oz-
> SeHLuynCSyblzo3_bvshDg&e=
> > >> > - Another email about a possible GCC fix on September 5th
> (David Wilder)
> > >>
> > >> As Dave mentioned that is only expected in GCC 9.
> > >>
> > >> > - There was a private reply on September 27th, confirming
> an IBM support
> > >> > - and nothing else
> > >> >
> > >> > Nobody at IBM requests to get a compilation fix for ppc64.
> > >>
> > >> Yes, we do need fixes for ppc64.
> > >>
> > >> (1)
> > >> INVALID URI REMOVED
>
u=http-3A__mails.dpdk.org_archives_dev_2018-2DAugust_110499.html&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=co4lCofxrQP11yIVMply-QYvsUyeKJkYY_jL1QVgeGA&m=QE2-
>
XfLmWX5fRwewYIIMAHJI_FETkneZA1XxK2aFv0o&s=XgjcGK0kIYU4y3K6zUMcAcVZxxzDYoUUm90oFuzGII8&e=
> > >> (2)
> > >> INVALID URI REMOVED
>
u=http-3A__mails.dpdk.org_archives_dev_2018-2DSeptember_110961.html&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=co4lCofxrQP11yIVMply-QYvsUyeKJkYY_jL1QVgeGA&m=QE2-
> XfLmWX5fRwewYIIMAHJI_FETkneZA1XxK2aFv0o&s=5XZlfxsqUXgL-
> aFscHGJgdDiqhKnfjz7Kx4KNj2J5Ck&e=
> > >>
> > >> Based on the above 2 URLs (tested both by Takeshi and David Wiler),
we
> > >> assumed that it would get picked up in 18.11.
> > >> We have been more focussed on 17.11 (and likely dropped
> > >> the ball on 18.11)
> > >> since 17.11 is an LTS release and we have had lots of problems on
> > >> ppc64.
> > >
> > > Note that 18.11 is also LTS.
Yes, we do realize that 18.11 is an LTS release. Since there is a larger
usage of
17.11 we have been focussed on that. Attempting to catch up with 18.11 as
well.
> > >
> > >> Should be submitting patch to fix those issues shortly.
> > >
> > > Sorry, I have some doubts for two reasons:
> > > - track records
> > > - technical reality: there is no perfect solution outside of GCC
> > >
> > >> We have built 18.11-rc1 with the fix above (1), and it does work on
> > >> ppc64le.
> > >
> > > But it would break C++ applications.
> > >
> > >> An updated version of:
> > >>
> > >> (3)
> > >> INVALID URI REMOVED
>
u=http-3A__mails.dpdk.org_archives_dev_2018-2DAugust_109926.html&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=co4lCofxrQP11yIVMply-QYvsUyeKJkYY_jL1QVgeGA&m=QE2-
> XfLmWX5fRwewYIIMAHJI_FETkneZA1XxK2aFv0o&s=urcohXf8f-
> T9doxPSqC3wRWT__d0nVmO6QftUwIvcG0&e=
> > >>
> > >> also builds on ppc64. The latter has the advantage of possibly not
> > >> breaking existing applications.
> >
> > I am not seeing any build breaks on upstream code with the
> > net-mlx5-fix-build-on-PPC64.patch applied.
> >
> > > But it fixes only mlx5.
> > > stdbool is used in many other places.
> > > Which PMDs are you compiling?
> >
> > CONFIG_RTE_LIBRTE_ARK_PMD=y
> > CONFIG_RTE_LIBRTE_AXGBE_PMD=y
> > CONFIG_RTE_LIBRTE_BNXT_PMD=y
> > CONFIG_RTE_LIBRTE_CXGBE_PMD=y
> > CONFIG_RTE_LIBRTE_DPAA_PMD=y
> > CONFIG_RTE_LIBRTE_DPAA2_PMD=y
> > CONFIG_RTE_LIBRTE_ENETC_PMD=y
> > CONFIG_RTE_LIBRTE_ENA_PMD=y
> > CONFIG_RTE_LIBRTE_EM_PMD=y
> > CONFIG_RTE_LIBRTE_IGB_PMD=y
> > CONFIG_RTE_LIBRTE_I40E_PMD=y
> > CONFIG_RTE_LIBRTE_AVF_PMD=y
> > CONFIG_RTE_LIBRTE_MLX5_PMD=y
> > CONFIG_RTE_LIBRTE_NFP_PMD=y
> > CONFIG_RTE_LIBRTE_QEDE_PMD=y
> > CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD=y
> > CONFIG_RTE_LIBRTE_LIO_PMD=y
> > CONFIG_RTE_LIBRTE_OCTEONTX_PMD=y
> > CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
> > CONFIG_RTE_LIBRTE_NETVSC_PMD=y
> > CONFIG_RTE_LIBRTE_VDEV_NETVSC_PMD=y
> > CONFIG_RTE_LIBRTE_IFC_PMD=y
> > CONFIG_RTE_TEST_PMD=y
We maybe compiling many PMDs, but for testing purposes mlx5 will be the
main focus on the Power platform, particularly P9.
> >
> > > Are you compiling examples?
Yes, please see below for additional details.
> >
> > Yes, no build issues seen.
> >
> > >> > And there was no issue raised after 18.11-rc1 release.
> > >> > I guess it means DPDK is not used on ppc64.
> > >> > In this case, we should mark the ppc port as unmaintained for
18.11.
> > >> >
> > >> > OR SHOULD I USE MY CAPS LOCK AGAIN?
> > >>
> > >> Thanks for your patience while we iron out the issues.
> > >> Hopefully, we don't need the CAPS LOCK again.
> > >
> > > We have to mention the ppc64 incompatibility in 18.11 release notes.
> > > Either it stays as is and we declare DPDK 18.11 not supported on
> > > IBM platforms, or we fix it and document the limitations.
> >
> > If net-mlx5-fix-build-on-PPC64.patch is accepted I feel power can be
> > listed as supported for 18.11.
>
> I sent this last patch which was thought by Christian (Canonical) and
> Adrien (6WIND). It is just fixing the compilation.
> Is there someone at IBM checking that basic DPDK features are working?
Yes, we are in the process of attempting to run DTS and other tests as
well.
While we learn all of this, we didn't pay enough attention to some of the
recent 18.X releases.
Thanks
Pradeep
pradeep@us.ibm.com
@@ -37,6 +37,17 @@
#include <string.h>
/*To include altivec.h, GCC version must >= 4.8 */
#include <altivec.h>
+/*
+ * Compilation workaround for PPC64 targets when AltiVec is fully
+ * enabled e.g. with std=c11. Otherwise there would be a type conflict
+ * of "bool" between stdbool and altivec.
+ */
+#if defined(__PPC64__) && !defined(__APPLE_ALTIVEC__)
+ #undef bool
+ /* redefine as in stdbool.h */
+ #define bool _Bool
+#endif
+
#ifdef __cplusplus
extern "C" {