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 <d...@adax.com> Date: Thursday, March 10, 2022 at 5:59 PM To: "Sanford, Robert" <rsanf...@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 <d...@adax.com> wrote: > > On Thu, Mar 10, 2022 at 11:46 AM Sanford, Robert <rsanf...@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.
