[dpdk-dev] [RFC PATCH] eal: rte_rand yields only 62 random bits

[Stephen Hemminger]

Plus the driver and sched uses really only need of few bits of crap random
number. Probably simple BSD random (32 bits)
is more than enough

On Mon, Mar 30, 2015 at 6:51 PM, Neil Horman <nhorman at tuxdriver.com> wrote:

> On Mon, Mar 30, 2015 at 06:19:28PM -0400, Robert Sanford wrote:
> > Yes, applications have many choices for PRNGs. But, we still need one
> > internally for the following libs: PMDs (e1000, fm10k, i40e, ixgbe,
> virtio,
> > xenvirt), sched, and timer.
> >
> They can be updated to use the apropriate rng from an external library.
> Neil
>
> >
> > On Fri, Mar 27, 2015 at 8:03 PM, Stephen Hemminger <
> > stephen at networkplumber.org> wrote:
> > > I would argue remove rte_rand from DPDK.
> >
> >
> >
> > On Mon, Mar 30, 2015 at 1:28 AM, Stephen Hemminger <
> > stephen at networkplumber.org> wrote:
> >
> > > if some one needs PRNG, th GNU scientific library has lots of them
> > >
> > >
> https://www.gnu.org/software/gsl/manual/html_node/Random-number-generator-algorithms.html
> > >
> > > On Fri, Mar 27, 2015 at 5:38 PM, Matthew Hall <mhall at mhcomputing.net>
> > > wrote:
> > >
> > > > On Fri, Mar 27, 2015 at 05:03:02PM -0700, Stephen Hemminger wrote:
> > > > > I would argue remove rte_rand from DPDK.
> > > >
> > > > +1
> > > >
> > > > To paraphrase Donald Knuth, "Random numbers should not be generated
> > > [using
> > > > a
> > > > function coded] at random."
> > > >
> > > > It'd be better to fix libc, or considering that has a slow dev cycle
> and
> > > > platform compatibility limits, use some simple, semi-random,
> > > > high-performance
> > > > BSD licensed routine from a known-good library.
> > > >
> > > > Matthew.
> > > >
> > >
> >
>