On 2024-07-29 20:16, Wathsala Wathawana Vithanage wrote:
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.
I feel no obligation to offer (potentially relatively uninformed) DPDK
users with options which I suspect have no benefits, only drawbacks. In
the x86_64 HW RNG case, I think it's fair to say we *know* it's bad idea
to use it as a high-performance CSRNG. In the ARM case, you choose to
leave us in the dark, so I can only assume it looks similar there.
The typical networking SoC's crypto-related hardware offload can pretty
much always demonstrate benefits.
