From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 14A97A0555;
	Wed, 25 May 2022 17:45:53 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id B8A8040146;
	Wed, 25 May 2022 17:45:52 +0200 (CEST)
Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com
 [209.85.215.182])
 by mails.dpdk.org (Postfix) with ESMTP id 8D575400EF
 for <dev@dpdk.org>; Wed, 25 May 2022 17:45:51 +0200 (CEST)
Received: by mail-pg1-f182.google.com with SMTP id s68so2916198pgs.10
 for <dev@dpdk.org>; Wed, 25 May 2022 08:45:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
 h=date:from:to:cc:subject:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding;
 bh=AN8Z3Li1jAGap21Ypci5qlZvTfc52d/5lg2ltNzuP2g=;
 b=HRkAscciT0+xhF8Pg+O7YrKFvg1h0zBstKrupmCXPBoXbUzaYH3P+sGLYTPbgLjLvZ
 TrCZATwX5Kvytj5QzAV22WI3iWTFA4pietS4vHUYsLUtEpQkRAk208oXKA481PKYbTEz
 DrhCzcRSYEgucvTBH09InZsuzyU+xPfCqWQkTQBBGnx9qKJORjWXfU4RRqopC2Q54zgf
 0OeLSjpha2S+AhJOmSYM62mnDMIN4NOrkl3zQ7EMrUNGBdpnYE48+xKvGRKZwEtBfPR+
 ObLGZlPK9M8NGt+XCfQ1AGRBuD6EdlN36eFlSrDHuaBr0Z/xMCqR3/IY/t/a7l8PQ/hw
 P+jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
 bh=AN8Z3Li1jAGap21Ypci5qlZvTfc52d/5lg2ltNzuP2g=;
 b=zKvGezE5t3GneTbSyib2zOkiXrl+27h2S1d/RUrclMh/CAxSctGr2srLmI3Aniuh13
 An0EeACeF7SZDmj5zPBxnwgXS2jsacIasQ9E9uRaW/S/H4OqdVvnwIgB3cloNhDeXmhJ
 GzKgXJbEGBNBpe1xCE33DOuNJJQeU/zQ/i8lei22qGNIeN7J0hpZKosz8JzXGjjIw7Zh
 mq/ySrhFOPLUCnfKOXNpFtN0ldu+8XyCMVQe0b9BmMD0DPb+pzO9kQN/xlPIEk/iJmEi
 +yFquFDbuZZ4jJAsER6qJKbpoz6Q8If93EMbNkJyy6G6FVZToPWT27jfs9FRJwaQgIqV
 yDzA==
X-Gm-Message-State: AOAM533vRrkeF7+QC98P37zPTcfjMiFGZZKB3H7bghcPclM3YAc591Oe
 pWQKqw1sPRkR+5rckyPx+BQu7A==
X-Google-Smtp-Source: ABdhPJzwpj/n/75i9v1KsL+1eAhie1yj0IZ3OKce+WYUBcpA7LuUgRMwpT4oqYhi1POtopHS+1YkGw==
X-Received: by 2002:a65:6d06:0:b0:3c6:890:5609 with SMTP id
 bf6-20020a656d06000000b003c608905609mr28697210pgb.357.1653493550506; 
 Wed, 25 May 2022 08:45:50 -0700 (PDT)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
 by smtp.gmail.com with ESMTPSA id
 jb4-20020a170903258400b0015e8d4eb1fcsm9483540plb.70.2022.05.25.08.45.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 25 May 2022 08:45:50 -0700 (PDT)
Date: Wed, 25 May 2022 08:45:47 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= <mattias.ronnblom@ericsson.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Ray Kinsella <mdr@ashroe.eu>
Subject: Re: [RFT v2 1/3] random: add rte_rand_float()
Message-ID: <20220525084547.13fd5f9f@hermes.local>
In-Reply-To: <589158f3-e42a-8e10-c5ad-5b05b4e6db04@ericsson.com>
References: <20220524184623.480646-1-stephen@networkplumber.org>
 <20220524221824.1037693-1-stephen@networkplumber.org>
 <20220524221824.1037693-2-stephen@networkplumber.org>
 <589158f3-e42a-8e10-c5ad-5b05b4e6db04@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Wed, 25 May 2022 14:45:37 +0000
Mattias R=C3=B6nnblom <mattias.ronnblom@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.
> >  =20
>=20
> Seems like a good addition to the API.
>=20
> > Signed-off-by: Stephen Hemminger <stephen@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(+)
> >=20
> > 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;
> >  =20
> >   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 +=3D rte_rand();
> >   			break;
> > +		case rand_type_float:
> > +			sum +=3D rte_rand_float() * UINT64_MAX;
> > +			break;
> >   		case rand_type_bounded_best_case:
> >   			sum +=3D rte_rand_max(BEST_CASE_BOUND);
> >   			break;
> > @@ -83,6 +89,7 @@ test_rand_perf(void)
> >   	printf("Pseudo-random number generation latencies:\n");
> >  =20
> >   	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);
> >  =20
> > diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_no=
tes/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``
> >  =20
> > +* ** Added function get random floating point number.**
> > +
> > +  Added the function ``rte_rand_float()`` to provide a pseudo-random
> > +  floating point number.
> > +
> >  =20
> >   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>
> >    =20
>=20
> Is this API available in FreeBSD? In Windows?
>=20
> >   #include <rte_branch_prediction.h>
> >   #include <rte_cycles.h>
> > @@ -173,6 +174,26 @@ rte_rand_max(uint64_t upper_bound)
> >   	return res;
> >   }
> >  =20
> > +double
> > +rte_rand_float(void)
> > +{
> > +	struct rte_rand_state *state =3D __rte_rand_get_state();
> > +	union ieee754_double u =3D {
> > +		.ieee =3D {
> > +			.negative =3D 0,
> > +			.exponent =3D IEEE754_DOUBLE_BIAS,
> > +		},
> > +	};
> > +	uint64_t val;
> > +
> > +	/* Take 64 bit random value and put it into the mantissa */
> > +	val =3D __rte_rand_lfsr258(state);
> > +	u.ieee.mantissa0 =3D val >> 32;	/* only 20 bits used */
> > +	u.ieee.mantissa1 =3D (uint32_t)val; =20
>=20
> Why do you have a cast here, and not for mantissa0? Both will incur a=20
> 64->32 conversion, assuming unsigned int is 32-bit (which it is on all=20
> platforms DPDK supports?).

Yes, cast there is unnecessary. A little concerned that some compiler
might complain about loss of precision.

>=20
> The naive implementation (i.e., (double)rte_rand() / (double)UINT64_MAX)=
=20
> would cost a floating point multiplication. That's why you access the=20
> underlying IEEE754 bits directly. Correct?

Yes, avoiding floating point math, and directly setting bits keeps full pre=
cision.