[dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Simon Kagstrom]

We have encountered a CPU where the AES-NI instruction set is disabled
due to export restrictions. Since the build machine and target machine
is different, using -native configs doesn't work, and on this CPU, the
application refuses to run due to the AES CPU flags being amiss.

The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
which allows us to add -mno-aes to the compile flags and resolve this
problem.

Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
ChangeLog:

v2:
* Put EXTRA_CFLAGS after MACHINE_CFLAGS to enable overriding values

 mk/rte.cpuflags.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index bec7bdd..4b30c6b 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -33,7 +33,7 @@
 # used to set the RTE_CPUFLAG_* environment variables giving details
 # of what instruction sets the target cpu supports.
 
-AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) -dM -E - < /dev/null)
+AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null)
 
 # adding flags to CPUFLAGS
 
-- 
1.9.1

Re: [dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Simon Kågström]

Hi Olivier!

Does this commit look OK now with the changes you proposed?

Thanks,
// Simon

On 2015-11-24 08:50, Simon Kagstrom wrote:
> We have encountered a CPU where the AES-NI instruction set is disabled
> due to export restrictions. Since the build machine and target machine
> is different, using -native configs doesn't work, and on this CPU, the
> application refuses to run due to the AES CPU flags being amiss.
> 
> The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
> which allows us to add -mno-aes to the compile flags and resolve this
> problem.
> 
> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> ---
> ChangeLog:
> 
> v2:
> * Put EXTRA_CFLAGS after MACHINE_CFLAGS to enable overriding values
> 
>  mk/rte.cpuflags.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
> index bec7bdd..4b30c6b 100644
> --- a/mk/rte.cpuflags.mk
> +++ b/mk/rte.cpuflags.mk
> @@ -33,7 +33,7 @@
>  # used to set the RTE_CPUFLAG_* environment variables giving details
>  # of what instruction sets the target cpu supports.
>  
> -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) -dM -E - < /dev/null)
> +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null)
>  
>  # adding flags to CPUFLAGS
>  
> 

Re: [dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Olivier MATZ]

Hi Simon,

On 12/04/2015 09:12 AM, Simon Kågström wrote:
> Hi Olivier!
> 
> Does this commit look OK now with the changes you proposed?
> 
> Thanks,
> // Simon
> 
> On 2015-11-24 08:50, Simon Kagstrom wrote:
>> We have encountered a CPU where the AES-NI instruction set is disabled
>> due to export restrictions. Since the build machine and target machine
>> is different, using -native configs doesn't work, and on this CPU, the
>> application refuses to run due to the AES CPU flags being amiss.
>>
>> The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
>> which allows us to add -mno-aes to the compile flags and resolve this
>> problem.
>>
>> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
>> ---
>> ChangeLog:
>>
>> v2:
>> * Put EXTRA_CFLAGS after MACHINE_CFLAGS to enable overriding values
>>
>>  mk/rte.cpuflags.mk | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
>> index bec7bdd..4b30c6b 100644
>> --- a/mk/rte.cpuflags.mk
>> +++ b/mk/rte.cpuflags.mk
>> @@ -33,7 +33,7 @@
>>  # used to set the RTE_CPUFLAG_* environment variables giving details
>>  # of what instruction sets the target cpu supports.
>>  
>> -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) -dM -E - < /dev/null)
>> +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null)
>>  
>>  # adding flags to CPUFLAGS
>>  
>>


Acked-by: Olivier Matz <olivier.matz@6wind.com>

Re: [dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Thomas Monjalon]

> >> We have encountered a CPU where the AES-NI instruction set is disabled
> >> due to export restrictions. Since the build machine and target machine
> >> is different, using -native configs doesn't work, and on this CPU, the
> >> application refuses to run due to the AES CPU flags being amiss.
> >>
> >> The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
> >> which allows us to add -mno-aes to the compile flags and resolve this
> >> problem.
> >>
> >> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> 
> Acked-by: Olivier Matz <olivier.matz@6wind.com>

Applied, thanks

Re: [dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Panu Matilainen]

On 12/04/2015 08:53 PM, Thomas Monjalon wrote:
>>>> We have encountered a CPU where the AES-NI instruction set is disabled
>>>> due to export restrictions. Since the build machine and target machine
>>>> is different, using -native configs doesn't work, and on this CPU, the
>>>> application refuses to run due to the AES CPU flags being amiss.
>>>>
>>>> The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
>>>> which allows us to add -mno-aes to the compile flags and resolve this
>>>> problem.
>>>>
>>>> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
>>
>> Acked-by: Olivier Matz <olivier.matz@6wind.com>
>
> Applied, thanks
>

This causes some complications on Fedora/RHEL due to fairly complex 
interactions with -Werror, -Wall and -Wformat-security mixup between 
upstream- and distro default compiler flags.

More specifically, when EXTRA_CFLAGS contains warning flag manipulation 
this patch can cause mismatch between other options that are okay 
elsewhere in dpdk make. A simple fix is to pass WERROR_FLAGS to 
AUTO_CPUFLAGS too to counter this, ie

diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index c6bb8de..28f203b 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -33,7 +33,7 @@
  # used to set the RTE_CPUFLAG_* environment variables giving details
  # of what instruction sets the target cpu supports.

-AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E 
- < /dev/null)
+AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) 
$(EXTRA_CFLAGS) -dM -E - < /dev/null)

  # adding flags to CPUFLAGS


I can send an official patch if this seems acceptable.

	- Panu -

Re: [dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Simon Kågström]

On 2015-12-07 09:33, Panu Matilainen wrote:
> On 12/04/2015 08:53 PM, Thomas Monjalon wrote:
>>>>> We have encountered a CPU where the AES-NI instruction set is disabled
>>>>> due to export restrictions. Since the build machine and target machine
>>>>> is different, using -native configs doesn't work, and on this CPU, the
>>>>> application refuses to run due to the AES CPU flags being amiss.
>>>>>
>>>>> The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
>>>>> which allows us to add -mno-aes to the compile flags and resolve this
>>>>> problem.
> 
> More specifically, when EXTRA_CFLAGS contains warning flag manipulation
> this patch can cause mismatch between other options that are okay
> elsewhere in dpdk make. A simple fix is to pass WERROR_FLAGS to
> AUTO_CPUFLAGS too to counter this, ie
> 
> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
> index c6bb8de..28f203b 100644
> --- a/mk/rte.cpuflags.mk
> +++ b/mk/rte.cpuflags.mk
> @@ -33,7 +33,7 @@
>  # used to set the RTE_CPUFLAG_* environment variables giving details
>  # of what instruction sets the target cpu supports.
> 
> -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E
> - < /dev/null)
> +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS)
> $(EXTRA_CFLAGS) -dM -E - < /dev/null)

Looks fine to me at least.

// Simon

Re: [dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications

[Thomas Monjalon]

2015-12-07 10:33, Panu Matilainen:
> On 12/04/2015 08:53 PM, Thomas Monjalon wrote:
> >>>> We have encountered a CPU where the AES-NI instruction set is disabled
> >>>> due to export restrictions. Since the build machine and target machine
> >>>> is different, using -native configs doesn't work, and on this CPU, the
> >>>> application refuses to run due to the AES CPU flags being amiss.
> >>>>
> >>>> The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper,
> >>>> which allows us to add -mno-aes to the compile flags and resolve this
> >>>> problem.
> >>>>
> >>>> Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> >>
> >> Acked-by: Olivier Matz <olivier.matz@6wind.com>
> >
> > Applied, thanks
> >
> 
> This causes some complications on Fedora/RHEL due to fairly complex 
> interactions with -Werror, -Wall and -Wformat-security mixup between 
> upstream- and distro default compiler flags.
> 
> More specifically, when EXTRA_CFLAGS contains warning flag manipulation 
> this patch can cause mismatch between other options that are okay 
> elsewhere in dpdk make. A simple fix is to pass WERROR_FLAGS to 
> AUTO_CPUFLAGS too to counter this, ie
> 
> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
> index c6bb8de..28f203b 100644
> --- a/mk/rte.cpuflags.mk
> +++ b/mk/rte.cpuflags.mk
> @@ -33,7 +33,7 @@
>   # used to set the RTE_CPUFLAG_* environment variables giving details
>   # of what instruction sets the target cpu supports.
> 
> -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E 
> - < /dev/null)
> +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) 
> $(EXTRA_CFLAGS) -dM -E - < /dev/null)
> 
>   # adding flags to CPUFLAGS
> 
> 
> I can send an official patch if this seems acceptable.

Yes this is acceptable.
Please explain the error you see in the commit message.