DPDK usage discussions
 help / color / mirror / Atom feed
From: Dan Gora <dg@adax.com>
To: "Sanford, Robert" <rsanford@akamai.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: meson options - build vs target machine cpuflags question
Date: Thu, 10 Mar 2022 19:54:48 -0300
Message-ID: <CAGyogRaCtBxrPZDN0PqNTwCmxWnH2fUriKNLOwGQqOVU34g8xg@mail.gmail.com> (raw)
In-Reply-To: <165CAE28-2A3E-4960-8E57-2EB9A19024DB@akamai.com>

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

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.


  reply	other threads:[~2022-03-10 22:55 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 [this message]
2022-03-10 22:58   ` Dan Gora
2022-03-10 23:39     ` Sanford, Robert
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:

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

  git send-email \
    --in-reply-to=CAGyogRaCtBxrPZDN0PqNTwCmxWnH2fUriKNLOwGQqOVU34g8xg@mail.gmail.com \
    --to=dg@adax.com \
    --cc=rsanford@akamai.com \
    --cc=users@dpdk.org \


* 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 \
	public-inbox-index users

Example config snippet for mirrors.
Newsgroup available over NNTP:

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