On 2024-07-28 00:45, Wathsala Wathawana Vithanage wrote:
If your patch are to have non-zero chance of being accepted, it should include
a base implementation based on getrandom() (and the Windows equivalent),
with the proper optimizations (e.g., batching entropy requests to the kernel
on a per-lcore basis).
You would also need to provide a rationale why ARM CPU HW random
numbers are better than what the kernel can offer. The only potential reason I
can think of is performance, so you would need to quantify that in some way.
In addition, reliance on CPU CSRNG would need to be a build-time option, and
disabled by default.
Plus, what I've mentioned several times, give a rationale why DPDK should
have this functionality.
Thank you for the clarification. If I understood correctly following is what's
needed.
...to have a non-zero chance of getting accepted.
1- An implementation of rte_csrand that calls getrandom() with per-core entropy
caching. Which will be the default for DPDK.
2- Build time flag to enable HW CSRNG for those who want to override the
default kernel getrandom() feature.
3- Rationale for why CPU HW CSRNG is required.
To elaborate on Item 3, the rationale is simple, we want to enable the HW
feature for those who need it.
That's circular. "The reason we want this feature implementation to be
included is to satisfy those who want this feature implementation."
Stop thinking like an ARM developer on a "software enablement" mission,
and start thinking like a DPDK library or application developer.
