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

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2024-07-29 20:16, Wathsala Wathawana Vithanage 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.
> 
> 

I feel no obligation to offer (potentially relatively uninformed) DPDK 
users with options which I suspect have no benefits, only drawbacks. In 
the x86_64 HW RNG case, I think it's fair to say we *know* it's bad idea 
to use it as a high-performance CSRNG. In the ARM case, you choose to 
leave us in the dark, so I can only assume it looks similar there.

The typical networking SoC's crypto-related hardware offload can pretty 
much always demonstrate benefits.