DPDK usage discussions
 help / color / mirror / Atom feed
From: "Sanford, Robert" <rsanford@akamai.com>
To: Dan Gora <dg@adax.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: meson options - build vs target machine cpuflags question
Date: Thu, 10 Mar 2022 23:39:12 +0000
Message-ID: <34563BA1-3187-4496-8392-9F5FFB006300@akamai.com> (raw)
In-Reply-To: <CAGyogRZpoc4+G4ZUc_xG7tVT9Lgq3XZmEPUyG6xQJ+Bfvcu1FA@mail.gmail.com>

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.


  reply	other threads:[~2022-03-10 23:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 14:46 Sanford, Robert
2022-03-10 22:54 ` Dan Gora
2022-03-10 22:58   ` Dan Gora
2022-03-10 23:39     ` Sanford, Robert [this message]
2022-03-11  0:00       ` Dan Gora
2022-03-11  1:18   ` Stephen Hemminger
2022-03-11  2:45     ` Dan Gora
2022-03-11  3:01       ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34563BA1-3187-4496-8392-9F5FFB006300@akamai.com \
    --to=rsanford@akamai.com \
    --cc=dg@adax.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK usage discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/users/0 users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 users users/ http://inbox.dpdk.org/users \
		users@dpdk.org
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git