From: Stephen Hemminger <stephen@networkplumber.org>
To: Dan Gora <dg@adax.com>
Cc: "Sanford, Robert" <rsanford@akamai.com>,
"users@dpdk.org" <users@dpdk.org>
Subject: Re: meson options - build vs target machine cpuflags question
Date: Thu, 10 Mar 2022 17:18:54 -0800 [thread overview]
Message-ID: <20220310171854.272f459b@hermes.local> (raw)
In-Reply-To: <CAGyogRaCtBxrPZDN0PqNTwCmxWnH2fUriKNLOwGQqOVU34g8xg@mail.gmail.com>
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.
next prev parent reply other threads:[~2022-03-11 1:19 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
2022-03-11 0:00 ` Dan Gora
2022-03-11 1:18 ` Stephen Hemminger [this message]
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=20220310171854.272f459b@hermes.local \
--to=stephen@networkplumber.org \
--cc=dg@adax.com \
--cc=rsanford@akamai.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).