RE: [PATCH] eal: add support for TRNG with Arm RNG feature

[Wathsala Wathawana Vithanage]

Hi Mattias,

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

I'm sorry, I'm not following this. Are you saying 

(a) adding a feature someone hasn't already asked for is impossible?

(b) it is impossible to add support for a feature that is only available in a 
few CPUs
of an architecture family?

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

Agree, from the numbers you are showing, it looks like they are all slow and
unsuitable for the data plane. But aren't there multi-plane DPDK applications
with control-plane threads that can benefit from a CSRNG, albeit slow?

Re: [PATCH] eal: add support for TRNG with Arm RNG feature

[Stephen Hemminger]

On Sat, 27 Jul 2024 15:45:55 +
Wathsala Wathawana Vithanage  wrote:

> Hi Mattias,
> 
> > > 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).
> >   
> 
> I'm sorry, I'm not following this. Are you saying 
> 
> (a) adding a feature someone hasn't already asked for is impossible?
> 
> (b) it is impossible to add support for a feature that is only available in a 
> few CPUs
> of an architecture family?
> 
> > 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?
> >   
> 
> Agree, from the numbers you are showing, it looks like they are all slow and
> unsuitable for the data plane. But aren't there multi-plane DPDK applications
> with control-plane threads that can benefit from a CSRNG, albeit slow?


The issue is that RDRAND and ARM RNG are both hardware features and the
trust level is debatable. (See Wikipedia on RDRAND). The DPDK should stay
out of this security fight because if DPDK offers direct access to HW
RNG then naive vendors will start using it in applications. Then when
it is revealed that some nation state has compromised HW RNG the blame
will land on DPDK for enabling this. Lets not not get into the supply
chain problem here. DPDK is an application environment, not a benchmark
environment.


The answer is to have API's like (rte_csrand) which then call the OS
level primitives. The trust is then passed to the OS. I trust Linus,
Theo de Raadt, and the rest of the open OS community to evaluate and
integrate the best secure random number generator.

Re: [PATCH] eal: add support for TRNG with Arm RNG feature

[Mattias Rönnblom]

On 2024-07-27 17:45, Wathsala Wathawana Vithanage wrote:

Hi Mattias,


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



I'm sorry, I'm not following this. Are you saying

(a) adding a feature someone hasn't already asked for is impossible?



No, not if you can explain why this feature will be useful. You guys 
made no such attempt.



(b) it is impossible to add support for a feature that is only available in a 
few CPUs
of an architecture family?



Cryptographically secure random numbers are available on all CPUs, via 
the operating system. Arguably, such random numbers are more secure than 
anything that a machine instruction can offer.


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.



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?



Agree, from the numbers you are showing, it looks like they are all slow and
unsuitable for the data plane. But aren't there multi-plane DPDK applications
with control-plane threads that can benefit from a CSRNG, albeit slow?

RE: [PATCH v1 1/4] power: refactor core power management library

[Tummala, Sivaprasad]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Dave,

From: Hunt, David 
Sent: Tuesday, July 23, 2024 3:34 PM
To: Tummala, Sivaprasad ; 
anatoly.bura...@intel.com; jer...@marvell.com; lihuis...@huawei.com; 
david.march...@redhat.com; Yigit, Ferruh ; 
konstantin.anan...@huawei.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v1 1/4] power: refactor core power management library

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


Hi Sivaprasad,

A couple of comments below:
On 20/07/2024 17:50, Sivaprasad Tummala wrote:

This patch introduces a comprehensive refactor to the core power

management library. The primary focus is on improving modularity

and organization by relocating specific driver implementations

from the 'lib/power' directory to dedicated directories within

'drivers/power/core/*'. The adjustment of meson.build files

enables the selective activation of individual drivers.



These changes contribute to a significant enhancement in code

organization, providing a clearer structure for driver implementations.

The refactor aims to improve overall code clarity and boost

maintainability. Additionally, it establishes a foundation for

future development, allowing for more focused work on individual

drivers and seamless integration of forthcoming enhancements.



Signed-off-by: Sivaprasad Tummala 


---

 drivers/meson.build   |   1 +

 .../power/acpi/acpi_cpufreq.c |  22 +-

 .../power/acpi/acpi_cpufreq.h |   6 +-

 drivers/power/acpi/meson.build|  10 +

 .../power/amd_pstate/amd_pstate_cpufreq.c |  24 +-

 .../power/amd_pstate/amd_pstate_cpufreq.h |   8 +-

 drivers/power/amd_pstate/meson.build  |  10 +

 .../power/cppc/cppc_cpufreq.c |  22 +-

 .../power/cppc/cppc_cpufreq.h |   8 +-

 drivers/power/cppc/meson.build|  10 +

 .../power/kvm_vm}/guest_channel.c |   0

 .../power/kvm_vm}/guest_channel.h |   0

 .../power/kvm_vm/kvm_vm.c |  22 +-

 .../power/kvm_vm/kvm_vm.h |   6 +-

 drivers/power/kvm_vm/meson.build  |  16 +

 drivers/power/meson.build |  12 +

 drivers/power/pstate/meson.build  |  10 +

 .../power/pstate/pstate_cpufreq.c |  22 +-

 .../power/pstate/pstate_cpufreq.h |   6 +-

 lib/power/meson.build |   7 +-

 lib/power/power_common.c  |   2 +-

 lib/power/power_common.h  |  16 +-

 lib/power/rte_power.c | 287 ++

 lib/power/rte_power.h | 139 ++---

 lib/power/rte_power_core_ops.h| 208 +

 lib/power/version.map |  14 +

 26 files changed, 618 insertions(+), 270 deletions(-)

 rename lib/power/power_acpi_cpufreq.c => drivers/power/acpi/acpi_cpufreq.c 
(95%)

 rename lib/power/power_acpi_cpufreq.h => drivers/power/acpi/acpi_cpufreq.h 
(98%)

 create mode 100644 drivers/power/acpi/meson.build

 rename lib/power/power_amd_pstate_cpufreq.c => 
drivers/power/amd_pstate/amd_pstate_cpufreq.c (95%)

 rename lib/power/power_amd_pstate_cpufreq.h => 
drivers/power/amd_pstate/amd_pstate_cpufreq.h (97%)

 create mode 100644 drivers/power/amd_pstate/meson.build

 rename lib/power/power_cppc_cpufreq.c => drivers/power/cppc/cppc_cpufreq.c 
(95%)

 rename lib/power/power_cppc_cpufreq.h => drivers/power/cppc/cppc_cpufreq.h 
(97%)

 create mode 100644 drivers/power/cppc/meson.build

 rename {lib/power => drivers/power/kvm_vm}/guest_channel.c (100%)

 rename {lib/power => drivers/power/kvm_vm}/guest_channel.h (100%)

 rename lib/power/power_kvm_vm.c => drivers/power/kvm_vm/kvm_vm.c (82%)

 rename lib/power/power_kvm_vm.h => drivers/power/kvm_vm/kvm_vm.h (98%)

 create mode 100644 drivers/power/kvm_vm/meson.build

 create mode 100644 drivers/power/meson.build

 create mode 100644 drivers/power/pstate/meson.build

 rename lib/power/power_pstate_cpufreq.c => 
drivers/power/pstate/pstate_cpufreq.c (96%)

 rename lib/power/power_pstate_cpufreq.h => 
drivers/power/pstate/pstate_cpufreq.h (98%)

 create mode 100644 lib/power/rte_power_core_ops.h

--snip--

diff --git a/lib/power/rte_power.c b/lib/power/rte_power.c

index 36c3f3da98..8afb5949b9 100644

--- a/lib/power/rte_power.c

+++ b/lib/power/rte_power.c

@@ -8,153 +8,86 @@

 #include 



 #include "rte_power.h"

-#include "power_acpi_cpufreq.h"

-#include "power_cppc_cpufreq.h"

 #include "power_common.h"

-#include "power_kvm_vm.h"

-#include "power_pstate_cpufreq.h"

-#include "power_amd_pstate_cpufreq.h"



-enum power_management_env global_default_env = PM_ENV_NOT_SET;

+static enum power_management_env global_default_env = PM_ENV_NOT_SET;

+static struct rte_power_core_ops *global_

RE: [PATCH v1 3/4] test/power: removed function pointer validations

[Tummala, Sivaprasad]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Dave,

Inline..

From: Hunt, David 
Sent: Monday, July 22, 2024 4:20 PM
To: Tummala, Sivaprasad ; 
anatoly.bura...@intel.com; jer...@marvell.com; lihuis...@huawei.com; 
david.march...@redhat.com; Yigit, Ferruh ; 
konstantin.anan...@huawei.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v1 3/4] test/power: removed function pointer validations

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.



On 20/07/2024 17:50, Sivaprasad Tummala wrote:

After refactoring the power library, power management operations are now

consistently supported regardless of the operating environment, making

function pointer checks unnecessary and thus removed from applications.



Signed-off-by: Sivaprasad Tummala 


---

 app/test/test_power.c | 95 ---

 app/test/test_power_cpufreq.c | 52 ---

 app/test/test_power_kvm_vm.c  | 36 -

 3 files changed, 183 deletions(-)





Hi Sivaprasad,

Nice work on the patch-set.

There's just four function pointer checks remaining that my compiler is 
complaining about. They are in examples/l3fwd-power/main.c (lines 443, 452, 
1350, 1353). It would be nice to have these removed as well, seeing as the 
functions are now inlines and don't need these checks.

[Siva] ACK. Will fix this in next version.

I'm running the patch set through some tests here, will keep you posted on 
progress.

Rgds,
Dave.


---snip---

RE: [PATCH v1 4/4] power/amd_uncore: uncore power management support for AMD EPYC processors

[Tummala, Sivaprasad]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Dave,

> -Original Message-
> From: Hunt, David 
> Sent: Tuesday, July 23, 2024 4:03 PM
> To: Tummala, Sivaprasad ;
> anatoly.bura...@intel.com; jer...@marvell.com; lihuis...@huawei.com;
> david.march...@redhat.com; Yigit, Ferruh ;
> konstantin.anan...@huawei.com
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v1 4/4] power/amd_uncore: uncore power management
> support for AMD EPYC processors
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 20/07/2024 17:50, Sivaprasad Tummala wrote:
> > This patch introduces driver support for power management of uncore
> > components in AMD EPYC processors.
> >
> > Signed-off-by: Sivaprasad Tummala 
> > ---
> >   drivers/power/amd_uncore/amd_uncore.c | 321
> ++
> >   drivers/power/amd_uncore/amd_uncore.h | 226 ++
> >   drivers/power/amd_uncore/meson.build  |  20 ++
> >   drivers/power/meson.build |   1 +
> >   4 files changed, 568 insertions(+)
> >   create mode 100644 drivers/power/amd_uncore/amd_uncore.c
> >   create mode 100644 drivers/power/amd_uncore/amd_uncore.h
> >   create mode 100644 drivers/power/amd_uncore/meson.build
> >
> > diff --git a/drivers/power/amd_uncore/amd_uncore.c
> > b/drivers/power/amd_uncore/amd_uncore.c
> > new file mode 100644
> > index 00..f15eaaa307
> > --- /dev/null
> > +++ b/drivers/power/amd_uncore/amd_uncore.c
> > @@ -0,0 +1,321 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2024 Advanced Micro Devices, Inc.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include "amd_uncore.h"
> > +#include "power_common.h"
> > +#include "e_smi/e_smi.h"
> > +
> > +#define MAX_UNCORE_FREQS 8
> > +#define MAX_NUMA_DIE 8
> > +
> > +#define BUS_FREQ 1000
> > +
> > +struct  __rte_cache_aligned uncore_power_info {
> > + unsigned int die;  /* Core die id */
> > + unsigned int pkg;  /* Package id */
> > + uint32_t freqs[MAX_UNCORE_FREQS];  /* Frequency array */
> > + uint32_t nb_freqs; /* Number of available freqs */
> > + uint32_t curr_idx; /* Freq index in freqs array */
> > + uint32_t max_freq;/* System max uncore freq */
> > + uint32_t min_freq;/* System min uncore freq */
> > +};
> > +
> > +static struct uncore_power_info
> > +uncore_info[RTE_MAX_NUMA_NODES][MAX_NUMA_DIE];
> > +static int esmi_initialized;
> > +
> > +static int
> > +set_uncore_freq_internal(struct uncore_power_info *ui, uint32_t idx)
> > +{
> > + int ret;
> > +
> > + if (idx >= MAX_UNCORE_FREQS || idx >= ui->nb_freqs) {
> > + POWER_LOG(DEBUG, "Invalid uncore frequency index %u, which "
> > + "should be less than %u", idx, ui->nb_freqs);
> > + return -1;
> > + }
> > +
> > + ret = esmi_apb_disable(ui->pkg, idx);
> > + if (ret != ESMI_SUCCESS) {
> > + POWER_LOG(ERR, "DF P-state '%u' set failed for pkg %02u",
> > + idx, ui->pkg);
> > + return -1;
> > + }
> > +
> > + POWER_DEBUG_LOG("DF P-state '%u' to be set for pkg %02u die %02u",
> > + idx, ui->pkg, ui->die);
> > +
> > + /* write the minimum value first if the target freq is less than 
> > current max
> */
> > + ui->curr_idx = idx;
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Fopen the sys file for the future setting of the uncore die frequency.
> > + */
>
>
> Comment may need updating, as function is not reading any sysfs files (for the
> moment, at least).
ACK! Will address this in next version.

>
>
> > +static int
> > +power_init_for_setting_uncore_freq(struct uncore_power_info *ui) {
> > + /* open and read all uncore sys files */
>
>
> Comment may need updating, as function is not reading any sysfs files (for the
> moment, at least).
ACK! Will address this in next version.
>
>
>
> > + /* Base max */
> > + ui->max_freq = 180;
> > + ui->min_freq = 120;
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Get the available uncore frequencies of the specific die by
> > +reading the
> > + * sys file.
> > + */
>
>
> Comment may need updating, as function is not reading any sysfs files. 3
> uncore frequencies hard-coded for the moment, may get via esmi or sysfs in
> the future.
ACK! Will address this in next version.
>
>
> > +static int
> > +power_get_available_uncore_freqs(struct uncore_power_info *ui) {
> > + int ret = -1;
> > + uint32_t i, num_uncore_freqs = 3;
> > + uint32_t fabric_freqs[] = {
> > + /* to be extended for probing support in future */
> > + 1800,
> > + 1444,
> > + 1200
> > + };
> > +
> > + if (num_uncore_freqs >= MAX_UNCORE_FREQS) {
> > + POWER_LOG(ERR, "T

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

[Wathsala Wathawana Vithanage]

> -Original Message-
> From: Stephen Hemminger 
> Sent: Saturday, July 27, 2024 10:54 AM
> To: Wathsala Wathawana Vithanage 
> Cc: Mattias Rönnblom ; Shunzhi Wen
> ; tho...@monjalon.net; Mattias Rönnblom
> ; Ruifeng Wang
> ; Bruce Richardson ;
> Tyler Retzlaff ; Min Zhou
> ; David Christensen ; Stanislaw
> Kardach ; Konstantin Ananyev
> ; dev@dpdk.org; nd ; Jack
> Bond-Preston ; Dhruv Tripathi
> ; Honnappa Nagarahalli
> 
> Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature
> 
> On Sat, 27 Jul 2024 15:45:55 +
> Wathsala Wathawana Vithanage  wrote:
> 
> > Hi Mattias,
> >
> > > > 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).
> > >
> >
> > I'm sorry, I'm not following this. Are you saying
> >
> > (a) adding a feature someone hasn't already asked for is impossible?
> >
> > (b) it is impossible to add support for a feature that is only
> > available in a few CPUs of an architecture family?
> >
> > > 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?
> > >
> >
> > Agree, from the numbers you are showing, it looks like they are all
> > slow and unsuitable for the data plane. But aren't there multi-plane
> > DPDK applications with control-plane threads that can benefit from a
> CSRNG, albeit slow?
> 
> 
> The issue is that RDRAND and ARM RNG are both hardware features and the
> trust level is debatable. (See Wikipedia on RDRAND). The DPDK should stay
> out of this security fight because if DPDK offers direct access to HW RNG then
> naive vendors will start using it in applications. Then when it is revealed 
> that
> some nation state has compromised HW RNG the blame will land on DPDK for
> enabling this. Lets not not get into the supply chain problem here. DPDK is an
> application environment, not a benchmark environment.
> 
> 
> The answer is to have API's like (rte_csrand) which then call the OS level
> primitives. The trust is then passed to the OS. I trust Linus, Theo de Raadt, 
> and
> the rest of the open OS community to evaluate and integrate the best secure
> random number generator.

Perhaps, you missed my previous email, I understand your concern. Is it 
acceptable
to you if rte_csrand uses the kernel RNG by default and has a build/run-time
parameter to switch to HW RNG for those who consciously make that decision?

RE: [PATCH] eal: add support for TRNG with Arm RNG feature

[Wathsala Wathawana Vithanage]

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

Re: [PATCH] eal: add support for TRNG with Arm RNG feature

[Stephen Hemminger]

On Sat, 27 Jul 2024 22:27:05 +
Wathsala Wathawana Vithanage  wrote:

> > The answer is to have API's like (rte_csrand) which then call the OS level
> > primitives. The trust is then passed to the OS. I trust Linus, Theo de 
> > Raadt, and
> > the rest of the open OS community to evaluate and integrate the best secure
> > random number generator.  
> 
> Perhaps, you missed my previous email, I understand your concern. Is it 
> acceptable
> to you if rte_csrand uses the kernel RNG by default and has a build/run-time
> parameter to switch to HW RNG for those who consciously make that decision?

No, because then DPDK is endorsing use of HW RNG as sole source of randomness.
If someone really, really wants to do that they can put in their own code
in their own application.