meson options - build vs target machine cpuflags question

meson options - build vs target machine cpuflags question

[Sanford, Robert]

Hello All,

We build a DPDK 21.05 app on Intel x86 machines with RDSEED in cpuflags, and may run it on machines *without* RDSEED.
This results in a fatal error ...
ERROR: This system does not support "RDSEED".
Please check that RTE_MACHINE is set correctly.
EAL: FATAL: unsupported cpu type.

I try adding -Dplatform=haswell when running meson, (because gcc man page indicates that haswell is last arch w/o RDSEED) but get the same result.
Until we resolve it, our workaround is changing the error-out in rte_cpu_is_supported() to just print a warning and continue.
We don't have direct access to automated build machines, we go through change request processes, and so we can't rapidly try too many things.

Is there a better meson option, such as machine=haswell, or something else that will work?

Thanks in advance,
Robert Sanford

Re: meson options - build vs target machine cpuflags question

[Dan Gora]

On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanford@akamai.com> wrote:
>
> Hello All,
>
> We build a DPDK 21.05 app on Intel x86 machines with RDSEED in cpuflags, and may run it on machines *without* RDSEED.
> This results in a fatal error ...
> ERROR: This system does not support "RDSEED".
> Please check that RTE_MACHINE is set correctly.
> EAL: FATAL: unsupported cpu type.
>
> I try adding -Dplatform=haswell when running meson, (because gcc man page indicates that haswell is last arch w/o RDSEED) but get the same result.
> Until we resolve it, our workaround is changing the error-out in rte_cpu_is_supported() to just print a warning and continue.
> We don't have direct access to automated build machines, we go through change request processes, and so we can't rapidly try too many things.
>
> Is there a better meson option, such as machine=haswell, or something else that will work?
>
> Thanks in advance,
> Robert Sanford

I tried four times to get a simple fix for this (and the lack of
getentropy() on older glibc) to determine the entropy source at run
time and got nothing but an endless raft of shit and ridiculous
criticisms that I completely gave up trying to contribute to DPDK ever
again.

The DPDK developers think that it's your responsibility to have a
separate build system for each of your target systems and platforms
and that if you don't you're basically a big dummy.

Don't believe me?  Go look through the archives:

"[PATCH 2/2] eal: resolve getentropy at run time for random seed"
"[PATCH v4 2/2] eal: emulate glibc getentropy for initial random seed".

I suggest that you just fork DPDK and use one of those patches and
just maintain a separate DPDK tree.  That's what I did.  It's way
easier than trying to get anything upstream.

thanks
dan

Re: meson options - build vs target machine cpuflags question

[Dan Gora]

On Thu, Mar 10, 2022 at 7:54 PM Dan Gora <dg@adax.com> wrote:
>
> On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanford@akamai.com> wrote:
> >
> > Hello All,
> >
> > We build a DPDK 21.05 app on Intel x86 machines with RDSEED in cpuflags, and may run it on machines *without* RDSEED.
> > This results in a fatal error ...
> > ERROR: This system does not support "RDSEED".
> > Please check that RTE_MACHINE is set correctly.
> > EAL: FATAL: unsupported cpu type.
> >
> > I try adding -Dplatform=haswell when running meson, (because gcc man page indicates that haswell is last arch w/o RDSEED) but get the same result.
> > Until we resolve it, our workaround is changing the error-out in rte_cpu_is_supported() to just print a warning and continue.
> > We don't have direct access to automated build machines, we go through change request processes, and so we can't rapidly try too many things.
> >
> > Is there a better meson option, such as machine=haswell, or something else that will work?
> >
> > Thanks in advance,
> > Robert Sanford
>
> I tried four times to get a simple fix for this (and the lack of
> getentropy() on older glibc) to determine the entropy source at run
> time and got nothing but an endless raft of shit and ridiculous
> criticisms that I completely gave up trying to contribute to DPDK ever
> again.
>
> The DPDK developers think that it's your responsibility to have a
> separate build system for each of your target systems and platforms
> and that if you don't you're basically a big dummy.
>
> Don't believe me?  Go look through the archives:
>
> "[PATCH 2/2] eal: resolve getentropy at run time for random seed"
> "[PATCH v4 2/2] eal: emulate glibc getentropy for initial random seed".

Sorry, those are the getentropy() fixes.  This is the fix to determine
RDSEED at runtime:

"[PATCH 0/2] eal: choose initial PRNG seed source at runtime"

It was acked but I don't think that it was ever merged.

Re: meson options - build vs target machine cpuflags question

[Sanford, Robert]

Hi Dan,
Thanks for the response. It is a lot of work and patience to get a change accepted. I admire all the guys who do it on a regular basis.

My problem turns out to be twofold: 1) Build machine has a CPU flag that the target does not have, and I was building "native".
2) Since I was building native, I was enabling RDSEED instructions even though the CPU doesn't support them. Fortunately, getentropy(3) works in our env.

I found the answer, by digging into the meson.build files, especially in config/ and config/x86/, and the resulting files created in the build dir.
Passing -Dplatform=haswell to meson did almost nothing AFAICS, still "native".
When I switch to -Dmachine=haswell, it has the desired effect on both build.ninja (generating -march=haswell for gcc)
and rte_build_config.h (disabling RDSEED).

Regards,
Robert Sanford

-----Original Message-----
From: Dan Gora <dg@adax.com>
Date: Thursday, March 10, 2022 at 5:59 PM
To: "Sanford, Robert" <rsanford@akamai.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: meson options - build vs target machine cpuflags question

On Thu, Mar 10, 2022 at 7:54 PM Dan Gora <dg@adax.com> wrote:
>
> On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanford@akamai.com> wrote:
> >
> > Hello All,
> >
> > We build a DPDK 21.05 app on Intel x86 machines with RDSEED in cpuflags, and may run it on machines *without* RDSEED.
> > This results in a fatal error ...
> > ERROR: This system does not support "RDSEED".
> > Please check that RTE_MACHINE is set correctly.
> > EAL: FATAL: unsupported cpu type.
> >
> > I try adding -Dplatform=haswell when running meson, (because gcc man page indicates that haswell is last arch w/o RDSEED) but get the same result.
> > Until we resolve it, our workaround is changing the error-out in rte_cpu_is_supported() to just print a warning and continue.
> > We don't have direct access to automated build machines, we go through change request processes, and so we can't rapidly try too many things.
> >
> > Is there a better meson option, such as machine=haswell, or something else that will work?
> >
> > Thanks in advance,
> > Robert Sanford
>
> I tried four times to get a simple fix for this (and the lack of
> getentropy() on older glibc) to determine the entropy source at run
> time and got nothing but an endless raft of shit and ridiculous
> criticisms that I completely gave up trying to contribute to DPDK ever
> again.
>
> The DPDK developers think that it's your responsibility to have a
> separate build system for each of your target systems and platforms
> and that if you don't you're basically a big dummy.
>
> Don't believe me?  Go look through the archives:
>
> "[PATCH 2/2] eal: resolve getentropy at run time for random seed"
> "[PATCH v4 2/2] eal: emulate glibc getentropy for initial random seed".

Sorry, those are the getentropy() fixes.  This is the fix to determine
RDSEED at runtime:

"[PATCH 0/2] eal: choose initial PRNG seed source at runtime"

It was acked but I don't think that it was ever merged.

Re: meson options - build vs target machine cpuflags question

[Dan Gora]

On Thu, Mar 10, 2022 at 8:39 PM Sanford, Robert <rsanford@akamai.com> wrote:
>
> Hi Dan,
> Thanks for the response. It is a lot of work and patience to get a change accepted. I admire all the guys who do it on a regular basis.
>
> My problem turns out to be twofold: 1) Build machine has a CPU flag that the target does not have, and I was building "native".
> 2) Since I was building native, I was enabling RDSEED instructions even though the CPU doesn't support them. Fortunately, getentropy(3) works in our env.
>
> I found the answer, by digging into the meson.build files, especially in config/ and config/x86/, and the resulting files created in the build dir.
> Passing -Dplatform=haswell to meson did almost nothing AFAICS, still "native".
> When I switch to -Dmachine=haswell, it has the desired effect on both build.ninja (generating -march=haswell for gcc)
> and rte_build_config.h (disabling RDSEED).

yeah I recall that the meson makefiles had a couple of changes that
needed to be done.  The patch worked by compiling the code with the
RDSEED instructions regardless of whether or not the build platform
supported them, but then checking the CPU flags at run time to see if
it could be accessed or not.  But that should work too, you just can't
access RDSEED on platforms which support it, but whatever..
getentropy() will work.

thanks
dan

Re: meson options - build vs target machine cpuflags question

[Stephen Hemminger]

On Thu, 10 Mar 2022 19:54:48 -0300
Dan Gora <dg@adax.com> wrote:

> On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanford@akamai.com> wrote:
> >
> > Hello All,
> >
> > We build a DPDK 21.05 app on Intel x86 machines with RDSEED in cpuflags, and may run it on machines *without* RDSEED.
> > This results in a fatal error ...
> > ERROR: This system does not support "RDSEED".
> > Please check that RTE_MACHINE is set correctly.
> > EAL: FATAL: unsupported cpu type.
> >
> > I try adding -Dplatform=haswell when running meson, (because gcc man page indicates that haswell is last arch w/o RDSEED) but get the same result.
> > Until we resolve it, our workaround is changing the error-out in rte_cpu_is_supported() to just print a warning and continue.
> > We don't have direct access to automated build machines, we go through change request processes, and so we can't rapidly try too many things.
> >
> > Is there a better meson option, such as machine=haswell, or something else that will work?
> >
> > Thanks in advance,
> > Robert Sanford  
> 
> I tried four times to get a simple fix for this (and the lack of
> getentropy() on older glibc) to determine the entropy source at run
> time and got nothing but an endless raft of shit and ridiculous
> criticisms that I completely gave up trying to contribute to DPDK ever
> again.
> 
> The DPDK developers think that it's your responsibility to have a
> separate build system for each of your target systems and platforms
> and that if you don't you're basically a big dummy.
> 
> Don't believe me?  Go look through the archives:
> 
> "[PATCH 2/2] eal: resolve getentropy at run time for random seed"
> "[PATCH v4 2/2] eal: emulate glibc getentropy for initial random seed".
> 
> I suggest that you just fork DPDK and use one of those patches and
> just maintain a separate DPDK tree.  That's what I did.  It's way
> easier than trying to get anything upstream.
> 
> thanks
> dan

The ideal solution would be able to use gcc function attributes and dyanmic
linking to do this at runtime - ie multiversion library.  But this opens a set
of different problems like compiler versions and testing.

Re: meson options - build vs target machine cpuflags question

[Dan Gora]

On Thu, Mar 10, 2022 at 10:19 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> The ideal solution would be able to use gcc function attributes and dyanmic
> linking to do this at runtime - ie multiversion library.  But this opens a set
> of different problems like compiler versions and testing.

Detecting RDSEED at run time doesn't require any of that, but working
around the possible absence of getentropy() does.  However none of my
proposed solutions, including dynamic linking was deemed suitable.. or
something, so I gave up.

Re: meson options - build vs target machine cpuflags question

[Stephen Hemminger]

On Thu, 10 Mar 2022 23:45:39 -0300
Dan Gora <dg@adax.com> wrote:

> On Thu, Mar 10, 2022 at 10:19 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > The ideal solution would be able to use gcc function attributes and dyanmic
> > linking to do this at runtime - ie multiversion library.  But this opens a set
> > of different problems like compiler versions and testing.  
> 
> Detecting RDSEED at run time doesn't require any of that, but working
> around the possible absence of getentropy() does.  However none of my
> proposed solutions, including dynamic linking was deemed suitable.. or
> something, so I gave up.

I don't blame you build systems suck.

Re: meson options - build vs target machine cpuflags question

[wang yufan]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

Here’s a draft for your email that you can send to inquire about resolving the RDSEED issue with DPDK:
________________________________
Subject: Inquiry Regarding DPDK RDSEED Support on Non-RDSEED Machines
Dear DPDK Development Team,
I hope this message finds you well.
I am currently facing an issue while building and running a DPDK 21.05 application on Intel x86 machines that have RDSEED in the CPU flags. We also need to run this application on machines that do not support RDSEED, which leads to the following fatal error:

ERROR: This system does not support "RDSEED".
Please check that RTE_MACHINE is set correctly.
EAL: FATAL: unsupported cpu type.


To address this, I attempted to add the -Dplatform=haswell option while running Meson, as I understand that Haswell is the last architecture without RDSEED support. However, I am still encountering the same error.
Currently, our workaround is to modify the error handling in rte_cpu_is_supported() to print a warning instead of exiting the application. However, this is not an ideal solution for us.
Given that we do not have direct access to automated build machines and must go through a change request process, it would be helpful to know if there is a more effective Meson configuration option (such as machine=haswell or anything else) that could help us resolve this issue.
I appreciate any guidance or suggestions you can provide to help us navigate this challenge.
Thank you in advance for your assistance!
Best regards,
wyf

[-- Attachment #2: Type: text/html, Size: 4472 bytes --]