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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.