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?
