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

[Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>]

Hi Mattias,

> > The primary goal of this patch is to provide a direct interface to HW,
> > instead of letting kernel handle it. This is not an API just for Arm
> > CPUs, as other vendors also have similar HW features. For instance,
> > Intel and AMD has support for x86 RDRAND and RDSEED instructions, thus
> > can easily implement this API.
> >
> 
> No DPDK library (or PMD) currently needs this functionality, and no
> application, to my knowledge, has asked for this. If an app or a DPDK library
> would require cryptographically secure random numbers, it would most likely
> require it on all CPU/OS platforms (and with all DPDK -march flags).
> 

I'm sorry, I'm not following this. Are you saying 

(a) adding a feature someone hasn't already asked for is impossible?

(b) it is impossible to add support for a feature that is only available in a few CPUs
of an architecture family?

> RDRAND is only available on certain x86_64 CPUs, and is incredibly slow
> - slower than getting entropy via the kernel, even with non-vDSO syscalls.
> 
> Agner Fog lists the RDRAND latency as ~3700 cc for Zen 2. Later generations of
> both AMD and Intel CPUs have much shorter latencies, but a reciprocal
> throughput so low that one have to wait thousands of clock cycles before
> issuing another RDRAND, or risk stalling the core.
> 
> My Raptor Lake seems to require ~1000 cc retire RDRAND, which is ~11x
> slower than getting entropy (in bulk) via getentropy().
> 
> What is the latency for the ARM equivalent? Does it also have a reciprocal
> throughput issue?
> 

Agree, from the numbers you are showing, it looks like they are all slow and
unsuitable for the data plane. But aren't there multi-plane DPDK applications
with control-plane threads that can benefit from a CSRNG, albeit slow?