On Wed, 25 May 2022 14:45:37 +0000
Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote:
> On 2022-05-25 00:18, Stephen Hemminger wrote:
> > The PIE code and other applications can benefit from having a
> > fast way to get a random floating point value. This new function
> > is equivalent to erand48_r in the standard library.
> >
>
> Seems like a good addition to the API.
>
> > Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
> > ---
> > app/test/test_rand_perf.c | 7 +++++++
> > doc/guides/rel_notes/release_22_07.rst | 5 +++++
> > lib/eal/common/rte_random.c | 21 +++++++++++++++++++++
> > lib/eal/include/rte_random.h | 17 +++++++++++++++++
> > lib/eal/version.map | 1 +
> > 5 files changed, 51 insertions(+)
> >
> > diff --git a/app/test/test_rand_perf.c b/app/test/test_rand_perf.c
> > index fe797ebfa1ca..f3602da5b2d4 100644
> > --- a/app/test/test_rand_perf.c
> > +++ b/app/test/test_rand_perf.c
> > @@ -20,6 +20,7 @@ static volatile uint64_t vsum;
> >
> > enum rand_type {
> > rand_type_64,
> > + rand_type_float,
> > rand_type_bounded_best_case,
> > rand_type_bounded_worst_case
> > };
> > @@ -30,6 +31,8 @@ rand_type_desc(enum rand_type rand_type)
> > switch (rand_type) {
> > case rand_type_64:
> > return "Full 64-bit [rte_rand()]";
> > + case rand_type_float:
> > + return "Floating point [rte_rand_float()]";
> > case rand_type_bounded_best_case:
> > return "Bounded average best-case [rte_rand_max()]";
> > case rand_type_bounded_worst_case:
> > @@ -55,6 +58,9 @@ test_rand_perf_type(enum rand_type rand_type)
> > case rand_type_64:
> > sum += rte_rand();
> > break;
> > + case rand_type_float:
> > + sum += rte_rand_float() * UINT64_MAX;
> > + break;
> > case rand_type_bounded_best_case:
> > sum += rte_rand_max(BEST_CASE_BOUND);
> > break;
> > @@ -83,6 +89,7 @@ test_rand_perf(void)
> > printf("Pseudo-random number generation latencies:\n");
> >
> > test_rand_perf_type(rand_type_64);
> > + test_rand_perf_type(rand_type_float);
> > test_rand_perf_type(rand_type_bounded_best_case);
> > test_rand_perf_type(rand_type_bounded_worst_case);
> >
> > diff --git a/doc/guides/rel_notes/release_22_07.rst
> > b/doc/guides/rel_notes/release_22_07.rst
> > index e49cacecefd4..128d4fca85b3 100644
> > --- a/doc/guides/rel_notes/release_22_07.rst
> > +++ b/doc/guides/rel_notes/release_22_07.rst
> > @@ -104,6 +104,11 @@ New Features
> > * ``RTE_EVENT_QUEUE_ATTR_WEIGHT``
> > * ``RTE_EVENT_QUEUE_ATTR_AFFINITY``
> >
> > +* ** Added function get random floating point number.**
> > +
> > + Added the function ``rte_rand_float()`` to provide a pseudo-random
> > + floating point number.
> > +
> >
> > Removed Items
> > -------------
> > diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c
> > index 4535cc980cec..024c3c41dc16 100644
> > --- a/lib/eal/common/rte_random.c
> > +++ b/lib/eal/common/rte_random.c
> > @@ -6,6 +6,7 @@
> > #include <x86intrin.h>
> > #endif
> > #include <unistd.h>
> > +#include <ieee754.h>
> >
>
> Is this API available in FreeBSD? In Windows?
>
> > #include <rte_branch_prediction.h>
> > #include <rte_cycles.h>
> > @@ -173,6 +174,26 @@ rte_rand_max(uint64_t upper_bound)
> > return res;
> > }
> >
> > +double
> > +rte_rand_float(void)
> > +{
> > + struct rte_rand_state *state = __rte_rand_get_state();
> > + union ieee754_double u = {
> > + .ieee = {
> > + .negative = 0,
> > + .exponent = IEEE754_DOUBLE_BIAS,
> > + },
> > + };
> > + uint64_t val;
> > +
> > + /* Take 64 bit random value and put it into the mantissa */
> > + val = __rte_rand_lfsr258(state);
> > + u.ieee.mantissa0 = val >> 32; /* only 20 bits used */
> > + u.ieee.mantissa1 = (uint32_t)val;
>
> Why do you have a cast here, and not for mantissa0? Both will incur a
> 64->32 conversion, assuming unsigned int is 32-bit (which it is on all
> platforms DPDK supports?).
Yes, cast there is unnecessary. A little concerned that some compiler
might complain about loss of precision.
>
> The naive implementation (i.e., (double)rte_rand() / (double)UINT64_MAX)
> would cost a floating point multiplication. That's why you access the
> underlying IEEE754 bits directly. Correct?
Yes, avoiding floating point math, and directly setting bits keeps full
precision.
