From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Morten Brørup" <mb@smartsharesystems.com>,
"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
Subject: RE: [PATCH v2] eal: allow setting random number generator seed
Date: Mon, 14 Sep 2026 12:04:16 +0000 [thread overview]
Message-ID: <8bf95eb0e0704401a1168a4e4fd238de@huawei.com> (raw)
In-Reply-To: <bd0242b5-44d8-40c7-8928-4586f0191fe1@lysator.liu.se>
> Den 2026-09-12 kl. 18:16, skrev Stephen Hemminger:
> > Many performance tests use rte_rand() and the random number
> > can perturb the results. Add an ability to override the automatic
> > random seed on DPDK startup.
>
> There is a way to seed the PRNG already, rte_srand(). Why the tests
> can't use this?
>
> Provided the test results depend on something that use the PRNG before
> the test driver has had the opportunity to call rte_srand(), controlling
> the *initial* seed may be required.
>
> I don't think this feature should be controlled by an environment
> variable. There is no precedent for that. If this functionality is
> deemed useful, it should be an EAL command line option, it seems to me.
+1
>
> >
> > This is not a security problem since rte_rand() is documented
> > as not being cryptographically secure.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v2 - fix header inclusion
> > - add docbook comment
> >
> > lib/eal/common/rte_random.c | 14 +++++++++++++-
> > lib/eal/include/rte_random.h | 8 +++++---
> > 2 files changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
> > index 576a32a46c..3cc0e3ec5f 100644
> > --- a/lib/eal/common/rte_random.c
> > +++ b/lib/eal/common/rte_random.c
> > @@ -8,6 +8,7 @@
> > #endif
> > #endif
> > #include <unistd.h>
> > +#include <stdlib.h>
> >
> > #include <rte_bitops.h>
> > #include <rte_branch_prediction.h>
> > @@ -247,7 +248,18 @@ eal_rand_init(void)
> >
> > RTE_LCORE_VAR_ALLOC(rand_state);
> >
> > - seed = __rte_random_initial_seed();
> > + const char *env = getenv("DPDK_RANDOM_SEED");
> > + if (env != NULL && *env != '\0') {
> > + char *end;
> > +
> > + errno = 0;
> > + seed = strtoull(env, &end, 0);
> > + if (errno != 0 || *end != '\0')
> > + rte_exit(EXIT_FAILURE,
> > + "invalid DPDK_RANDOM_SEED: %s\n", env);
>
> Is rte_exit() the way to deal with errors here? Not to be used in DPDK
> libraries, if I recall correctly.
Again, +1
Whole patch looks to me like a strange hack that completely ignores DPDK coding practices.
My vote is NACK.
>
> I would think logging an error would suffice. Or rte_eal_init_alert().
>
> > + } else {
> > + seed = __rte_random_initial_seed();
> > + }
> >
> > rte_srand(seed);
> > }
> > diff --git a/lib/eal/include/rte_random.h b/lib/eal/include/rte_random.h
> > index 15cbe6215a..bdd4001e78 100644
> > --- a/lib/eal/include/rte_random.h
> > +++ b/lib/eal/include/rte_random.h
> > @@ -20,9 +20,11 @@ extern "C" {
> > /**
> > * Seed the pseudo-random generator.
> > *
> > - * The generator is automatically seeded by the EAL init with a timer
> > - * value. It may need to be re-seeded by the user with a real random
> > - * value.
> > + * The generator is automatically seeded by the EAL init with
> > + * a system provided random entropy source. But for testing
> > + * it can be useful to force a repeatable starting point by
> > + * setting the initial seed. This can be done by setting
> > + * the `DPDK_RANDOM_SEED` environment variable.
> > *
> > * This function is not multi-thread safe in regards to other
> > * rte_srand() calls, nor is it in relation to concurrent rte_rand(),
next prev parent reply other threads:[~2026-09-14 12:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 22:58 [RFC] eal: allow setting random number generator seed Stephen Hemminger
2026-09-12 6:26 ` Morten Brørup
2026-09-12 16:16 ` [PATCH v2] " Stephen Hemminger
2026-09-14 11:29 ` Mattias Rönnblom
2026-09-14 12:04 ` Konstantin Ananyev [this message]
2026-09-14 16:47 ` Stephen Hemminger
2026-09-14 16:46 ` Stephen Hemminger
2026-09-14 9:05 ` [RFC] " Marat Khalili
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=8bf95eb0e0704401a1168a4e4fd238de@huawei.com \
--to=konstantin.ananyev@huawei.com \
--cc=dev@dpdk.org \
--cc=hofors@lysator.liu.se \
--cc=mattias.ronnblom@ericsson.com \
--cc=mb@smartsharesystems.com \
--cc=stephen@networkplumber.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