On Tue, Apr 14, 2020 at 11:37 PM Mattias Rönnblom
<mattias.ronnb...@ericsson.com> wrote:
>
> On 2020-04-14 15:35, David Marchand wrote:
> > On Tue, Apr 14, 2020 at 3:20 PM Mattias Rönnblom
> > <mattias.ronnb...@ericsson.com> wrote:
> >> On 2020-04-14 06:43, Tonghao Zhang wrote:
> >>> On Tue, Apr 14, 2020 at 12:07 PM Stephen Hemminger
> >>> <step...@networkplumber.org> wrote:
> >>>> On Sun, 12 Apr 2020 16:27:53 +0800
> >>>> xiangxia.m....@gmail.com wrote:
> >>>>
> >>>>> From: Tonghao Zhang <xiangxia.m....@gmail.com>
> >>>>>
> >>>>> When rte_rand_init is invoked, and the kernel
> >>>>> (kernel version < 3.17) running dpdk does't support
> >>>>> *getentropy, at the same time, the cpu does't support
> >>>>> rdseed, the rte_rand_init will invoke rte_get_timer_cycles
> >>>>> which function will invoke rte_get_hpet_cycles
> >>>>> (RTE_LIBEAL_USE_HPET was enabled) while *eal_hpet is not
> >>>>> allocated.
> >>>>>
> >>>>> Fixes: faf8fd252785 ("eal: improve entropy for initial PRNG seed")
> >>>>> Fixes: 3f002f069612 ("eal: replace libc-based random generation with
> >>>>> LFSR")
> >>>>>
> >>>>> Cc: sta...@dpdk.org
> >>>>>
> >>>>> Signed-off-by: Tonghao Zhang <xiangxia.m....@gmail.com>
> >>>> Are you sure this patch won't change current default to use HPET (which
> >>>> is slower)?
> >>> In rte_eal_timer_init (linux/eal_timer.c)， it will set
> >>> eal_timer_source = EAL_TIMER_TSC too.
> >>> So after rte_eal_init, eal_timer_source == EAL_TIMER_TSC which is the
> >>> default timer source actually.
> >>> Then this patch will affect RTE_INIT function which invoke
> >>> rte_get_timer_cycles. but hpet is not available yet.
> >>
> >> Would using rte_rdtsc() directly be an option?
> > s/rte_rdtsc/rte_get_tsc_cycles/
> >
> > This could work, but I am a bit surprised to see an initialisation in
> > a constructor.
> > The commitlog that moved rte_srand() from rte_eal_init does not
> > explain why it was moved.
> >
> >
> The initialization (i.e. automatic seeding) grew in complexity somewhat,
> and with the new rte_random.c file, it felt like it would have a good,
> new home.
>
>
> That said, maybe it would have been better to add an initialization
> function to the rte_random.h API, and have it called from
> rte_eal_init(), to avoid the ordering issues with constructors.
If we use that solution we can register a callback which invoked when
almost resources are available:
http://patches.dpdk.org/patch/68313/
> Yet
> another alternative would be to just move the seeding logic.
>
>
--
Best regards, Tonghao
