Re: [PATCH] eal: add support for TRNG with Arm RNG feature
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.
Re: [PATCH] eal: add support for TRNG with Arm RNG feature
On 2024-07-28 01:55, Stephen Hemminger wrote: 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. That's a good point. Even a build-time option (with the required caveats in the documentation) could be seen as an endorsement. A DPDK-based security library of some sort could provide hooks for custom RNGs.
ipsec on dpdk
Hi I am interested to do ipsec encoding and decoding in my dpdk application From my readings, i understand ipsec can be done one time in the nic (inline ipsec) or with multiple calls (rte_cryptodev_enqueue_burst, rte_cryptodev_dequeue_burst) 1. If ipsec is done by nic I only need to call rte_ipsec_pkt_process(...) without other functions? I use rte_eth_rx_burst to read from nic. 1. Where do I see list of nic that support nic inline ipsec? I believe not all dpdk nic support it. 2. How much does it impact performance ? is there a table of performance per nic? 3. My application is multi process, I can see in documentation : “Currently, the security library does not support the case of multi-process. It will be updated in the future releases.” From https://doc.dpdk.org/guides/prog_guide/rte_security.html So ipsec also is not supported for multi process application? Even if done inline by the nic? And what about non inline ipsec for multi process applications? 1. Is ip sec also supported in multi queue with rte flow in the inline ipsec ?
Re: [PATCH] eal: add support for TRNG with Arm RNG feature
On Sun, 28 Jul 2024 08:42:42 +0200 Mattias Rönnblom wrote: > > 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. The Linux kernel in arch/arm64/include/asm/archrandom.h has support already. The support includes lots of checks for capabilities and caveats for the limitations of the ARM implementation that are not reflected in this simplistic version.
RE: [PATCH] eal: add support for TRNG with Arm RNG feature
> > The Linux kernel in arch/arm64/include/asm/archrandom.h has support > already. The support includes lots of checks for capabilities and caveats for > the > limitations of the ARM implementation that are not reflected in this > simplistic > version. No, such checks are unnecessary, because (a) the patch already uses the capability check carried out by Linux kernel by checking the capabilities flag in auxiliary vector (AT_HWCAP). (b) it uses Arm acle intrinsic __rndr which is identical to the implementation in the Linux kernel where it checks PSTATE.NZCV bits.
RE: [PATCH] eal: add support for TRNG with Arm RNG feature
> > > 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. How does HW RNG become the sole source of randomness if the default is kernel's implementation of CSRNG? As far as I understand, endorsing is not same as optionality.
[PATCH v2 1/1] examples/l2fwd-jobstats: add delay to show stats
This patch addresses the issue by introducing a delay
before acquiring the lock in the loop. This delay allows for better
availability of the lock, ensuring that show_lcore_stats() can
periodically update the statistics even when forwarding jobs are running.
Fixes: 204896f8d66c ("examples/l2fwd-jobstats: add new example")
Cc: sta...@dpdk.org
Signed-off-by: Rakesh Kudurumalla
---
v2: updated commit message
examples/l2fwd-jobstats/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/l2fwd-jobstats/main.c b/examples/l2fwd-jobstats/main.c
index 308b8edd20..7bb38b290f 100644
--- a/examples/l2fwd-jobstats/main.c
+++ b/examples/l2fwd-jobstats/main.c
@@ -542,7 +542,7 @@ l2fwd_main_loop(void)
} while (likely(stats_read_pending == 0));
rte_spinlock_unlock(&qconf->lock);
- rte_pause();
+ rte_delay_us(10);
}
/* >8 End of minimize impact of stats reading. */
}
--
2.25.1
[PATCH v2 1/1] examples/l2fwd-jobstats: add delay to show stats
This patch addresses the issue by introducing a delay
before acquiring the lock in the loop. This delay allows for better
availability of the lock, ensuring that show_lcore_stats() can
periodically update the statistics even when forwarding jobs are running.
Fixes: 204896f8d66c ("examples/l2fwd-jobstats: add new example")
Cc: sta...@dpdk.org
Signed-off-by: Rakesh Kudurumalla
---
v2: updated commit message
examples/l2fwd-jobstats/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/l2fwd-jobstats/main.c b/examples/l2fwd-jobstats/main.c
index 308b8edd20..7bb38b290f 100644
--- a/examples/l2fwd-jobstats/main.c
+++ b/examples/l2fwd-jobstats/main.c
@@ -542,7 +542,7 @@ l2fwd_main_loop(void)
} while (likely(stats_read_pending == 0));
rte_spinlock_unlock(&qconf->lock);
- rte_pause();
+ rte_delay_us(10);
}
/* >8 End of minimize impact of stats reading. */
}
--
2.25.1
RE: [PATCH] eal: add support for TRNG with Arm RNG feature
> ...to have a non-zero chance of getting accepted. > I see too much uncertainty in that statement with "non-zero chance". As the maintainer of this library and someone with the community's best interest in mind, can you outline the requirements for a rte_csrand implementation with a higher degree of confidence? I want to know the criteria that must be satisfied for the acceptance probability to be close to 1. I'm sorry if I have not been abundantly clear on the requirements that I thought you would look for in such a patch. Maybe I misread your previous email. > > 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. We all think different in one way or the other, but what's more important is finding a common ground.
Re: [PATCH] eal: add support for TRNG with Arm RNG feature
On 2024-07-29 08:34, Wathsala Wathawana Vithanage wrote: ...to have a non-zero chance of getting accepted. I see too much uncertainty in that statement with "non-zero chance". As the maintainer of this library and someone with the community's best interest in mind, can you outline the requirements for a rte_csrand implementation with a higher degree of confidence? I want to know the criteria that must be satisfied for the acceptance probability to be close to 1. I'm sorry if I have not been abundantly clear on the requirements that I thought you would look for in such a patch. Maybe I misread your previous email. 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. 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. We all think different in one way or the other, but what's more important is finding a common ground.
