Re: [PATCH] eal: add support for TRNG with Arm RNG feature

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 29 Jul 2024 18:16:14 +0000
Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com> wrote:

> > 
> > Without a rationale why rte_csrand() functionality is something that should be
> > in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(),
> > it doesn't really matter how the patch set looks like.
> > 
> > I've repeatedly asked for this information, and you've repeatedly ignored it.
> > This does not further your cause.
> >   
>  
> I don't want to get into a debate on what's more superior because DPDK already have similar
> Setups, take OpenSSL and Marvell's security accelerator for instance. Rationale is simple it boils
> down to freedom of choice. 
> 
> I have been reiterating that I'm ready to make Kernel getrandom() the default in rte_csrand()
> and HW RNG (not limited Arm) a build time option along with your other demands for various
> optimizations. Having a build time option to enable HW CSRNG doesn't hinder your freedom to
> choose a CSRNG implementation of your linking. 
> Neither you nor I are in a place to decide what's right for others; the best we can do is to
> collaborate on providing them with options. Leave the decision to users, application developers,
> and integrators.
> 
> I believe that the coexistence of support for OpenSSL and other HW security accelerators in
> DPDK already establishes rationale and precedent.

Unless there is a specific direct usage in DPDK, my conclusion is that
there is no added benefit to users by adding this to the API in DPDK.
Users are free to use what they want, getentropy, HW instructions.