> 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. 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.
