On 2024-07-26 20:34, Shunzhi Wen wrote:
I'm missing a rationale here. Why is this useful?
This creates an API for HW that supports cryptographically secure random number
generation.
If you want to extend <rte_random.h> with a cryptographically secure
random number generator, that's fine.
To have an API that's only available on certain ARM CPUs is not.
NAK
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).
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?
A new function should be called something with "secure", rather than "true"
(which is a bit silly, since we might well live in a completely deterministic
universe). "secure" would more clearly communicate the intent, and also
doesn't imply any particular implementation.
Regarding the terminology, “cryptographically secure random number”
is a more accurate and meaningful term than “true random number.”
This change will be made in the description, and the function name will
be replaced with rte_csrand.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
