> > Without a rationale why rte_csrand() functionality is something that should be > in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(), > it doesn't really matter how the patch set looks like. > > I've repeatedly asked for this information, and you've repeatedly ignored it. > This does not further your cause. > I don't want to get into a debate on what's more superior because DPDK already have similar Setups, take OpenSSL and Marvell's security accelerator for instance. Rationale is simple it boils down to freedom of choice.
I have been reiterating that I'm ready to make Kernel getrandom() the default in rte_csrand() and HW RNG (not limited Arm) a build time option along with your other demands for various optimizations. Having a build time option to enable HW CSRNG doesn't hinder your freedom to choose a CSRNG implementation of your linking. Neither you nor I are in a place to decide what's right for others; the best we can do is to collaborate on providing them with options. Leave the decision to users, application developers, and integrators. I believe that the coexistence of support for OpenSSL and other HW security accelerators in DPDK already establishes rationale and precedent.
