RE: 24.11.2 patches review and test
> -Original Message- > From: Kevin Traynor > Sent: Friday, March 28, 2025 6:15 PM > To: sta...@dpdk.org > Cc: dev@dpdk.org; Abhishek Marathe ; > Ali Alnubani ; David Christensen > ; Hemant Agrawal ; > Stokes, Ian ; Jerin Jacob ; > Mcnamara, John ; Ju-Hyoung Lee > ; Kevin Traynor ; Luca > Boccassi ; Pei Zhang ; Raslan > Darawsheh ; Thomas Monjalon > ; yangh...@redhat.com > Subject: 24.11.2 patches review and test > > Hi all, > > Here is a list of patches targeted for stable release 24.11.2. > > The planned date for the final release is 14 April. > > Please help with testing and validation of your use cases and report any > issues/results with reply-all to this mail. For the final release the fixes > and > reported validations will be added to the release notes. > > A release candidate tarball can be found at: > > https://dpdk.org/browse/dpdk-stable/tag/?id=v24.11.2-rc1 > > These patches are located at branch 24.11 of dpdk-stable repo: > https://dpdk.org/browse/dpdk-stable/ > > Thanks. > > Kevin > > --- Update the test status for Intel part. dpdk24.11.2-rc1 all validation test done. no new issue is found. known issues: fix patch has been merged into main, but they not merged 24.11 LTS, so this issue still exists in 24.11.2-rc1 1. Bug 1606 - flow_filtering/flow_filtering_mismatch_rule: Some mismatch rule packets match the rule. - has fix patch: https://patches.dpdk.org/project/dpdk/patch/20250112075200.5020-1-shper...@nvidia.com/ 2. Linkville vfs can't forward packets - has fix patches: https://patches.dpdk.org/project/dpdk/list/?series=34939&archive=both&state=* * Build & CFLAG compile: cover the build test with latest GCC/Clang version on the following OS(all passed) - Ubuntu24.10/Ubuntu24.04.1 - RHEL9.4/RHEL9.5/RHEL10 beta - Fedora41 - FreeBSD14.2 - SUSE15.6 - OpenAnolis8.9 - AzureLinux3.0 * Function tests: All test done and there are two known issues. - i40E-(XXV710, X722) PF/VF: test scenarios including basic/RTE_FLOW/TSO/Jumboframe/checksum offload/mac_filter/VLAN/VXLAN/RSS, etc. - IXGBE-(82599, E610) PF/VF: test scenarios including basic/RTE_FLOW/TSO/Jumboframe/checksum offload/mac_filter/VLAN/VXLAN/RSS, etc. - ICE-(E810, E830, E2100) PF/VF: test scenarios including basic/Switch/Package Management/Flow Director/Advanced Tx/Advanced RSS/ACL/DCF/Flexible Descriptor, etc. - IPsec: test scenarios including ipsec/ipsec-gw/ipsec library basic test - QAT&SW/FIB library, etc. - Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing/VMAWARE ESXI 8.0, etc. - Cryptodev: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. - DLB: test scenarios including DLB2.0 and DLB2.5 - Other: test scenarios including AF_XDP, Power, CBDMA, DSA * Performance test: All test done and passed - Thoughput Performance - Cryptodev Latency - PF/VF NIC single core - XXV710/E810 NIC Performance Regards, Xu, Hailin
[PATCH] test/crypto: add test case for modex group 24
Add test case for modex group 24.
Signed-off-by: Gowrishankar Muthukrishnan
---
app/test/test_cryptodev_asym.c | 16 ++
app/test/test_cryptodev_mod_test_vectors.h | 227 +
2 files changed, 243 insertions(+)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 2377a18c72..6b74dd9a73 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -3923,6 +3923,14 @@ static struct unit_test_suite
cryptodev_openssl_asym_testsuite = {
"Modex Group 18 test",
ut_setup_asym, ut_teardown_asym,
modular_exponentiation, &modex_group_test_cases[5]),
+ TEST_CASE_NAMED_WITH_DATA(
+ "Modex Group 24 test",
+ ut_setup_asym, ut_teardown_asym,
+ modular_exponentiation, &modex_group_test_cases[6]),
+ TEST_CASE_NAMED_WITH_DATA(
+ "Modex Group 24 subgroup test",
+ ut_setup_asym, ut_teardown_asym,
+ modular_exponentiation, &modex_group_test_cases[7]),
TEST_CASE_ST(ut_setup_asym, ut_teardown_asym,
test_eddsa_sign_verify_all_curve),
TEST_CASES_END() /**< NULL terminate unit test array */
}
@@ -4010,6 +4018,14 @@ static struct unit_test_suite
cryptodev_octeontx_asym_testsuite = {
"Modex Group 18 test",
ut_setup_asym, ut_teardown_asym,
modular_exponentiation, &modex_group_test_cases[5]),
+ TEST_CASE_NAMED_WITH_DATA(
+ "Modex Group 24 test",
+ ut_setup_asym, ut_teardown_asym,
+ modular_exponentiation, &modex_group_test_cases[6]),
+ TEST_CASE_NAMED_WITH_DATA(
+ "Modex Group 24 subgroup test",
+ ut_setup_asym, ut_teardown_asym,
+ modular_exponentiation, &modex_group_test_cases[7]),
TEST_CASE_ST(ut_setup_asym, ut_teardown_asym,
test_ecdsa_sign_verify_all_curve),
TEST_CASE_ST(ut_setup_asym, ut_teardown_asym, test_sm2_sign),
diff --git a/app/test/test_cryptodev_mod_test_vectors.h
b/app/test/test_cryptodev_mod_test_vectors.h
index 34af2d73b7..5b4b795635 100644
--- a/app/test/test_cryptodev_mod_test_vectors.h
+++ b/app/test/test_cryptodev_mod_test_vectors.h
@@ -1319,6 +1319,233 @@ modex_test_data modex_group_test_cases[] = {
.len = 1024
},
},
+{
+ /*
+* Referenced from RFC 5114 for checking g^a mod p = A.
+* base and modulus data are from Section 2.3.
+* exponent and reminder data are from Appendix A.3.
+*/
+ .description = "Modular Exponentiation tests for Group 24",
+ .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
+ .base = {
+ .data = {
+ 0x3F, 0xB3, 0x2C, 0x9B, 0x73, 0x13, 0x4D, 0x0B,
+ 0x2E, 0x77, 0x50, 0x66, 0x60, 0xED, 0xBD, 0x48,
+ 0x4C, 0xA7, 0xB1, 0x8F, 0x21, 0xEF, 0x20, 0x54,
+ 0x07, 0xF4, 0x79, 0x3A, 0x1A, 0x0B, 0xA1, 0x25,
+ 0x10, 0xDB, 0xC1, 0x50, 0x77, 0xBE, 0x46, 0x3F,
+ 0xFF, 0x4F, 0xED, 0x4A, 0xAC, 0x0B, 0xB5, 0x55,
+ 0xBE, 0x3A, 0x6C, 0x1B, 0x0C, 0x6B, 0x47, 0xB1,
+ 0xBC, 0x37, 0x73, 0xBF, 0x7E, 0x8C, 0x6F, 0x62,
+ 0x90, 0x12, 0x28, 0xF8, 0xC2, 0x8C, 0xBB, 0x18,
+ 0xA5, 0x5A, 0xE3, 0x13, 0x41, 0x00, 0x0A, 0x65,
+ 0x01, 0x96, 0xF9, 0x31, 0xC7, 0x7A, 0x57, 0xF2,
+ 0xDD, 0xF4, 0x63, 0xE5, 0xE9, 0xEC, 0x14, 0x4B,
+ 0x77, 0x7D, 0xE6, 0x2A, 0xAA, 0xB8, 0xA8, 0x62,
+ 0x8A, 0xC3, 0x76, 0xD2, 0x82, 0xD6, 0xED, 0x38,
+ 0x64, 0xE6, 0x79, 0x82, 0x42, 0x8E, 0xBC, 0x83,
+ 0x1D, 0x14, 0x34, 0x8F, 0x6F, 0x2F, 0x91, 0x93,
+ 0xB5, 0x04, 0x5A, 0xF2, 0x76, 0x71, 0x64, 0xE1,
+ 0xDF, 0xC9, 0x67, 0xC1, 0xFB, 0x3F, 0x2E, 0x55,
+ 0xA4, 0xBD, 0x1B, 0xFF, 0xE8, 0x3B, 0x9C, 0x80,
+ 0xD0, 0x52, 0xB9, 0x85, 0xD1, 0x82, 0xEA, 0x0A,
+ 0xDB, 0x2A, 0x3B, 0x73, 0x13, 0xD3, 0xFE, 0x14,
+ 0xC8, 0x48, 0x4B, 0x1E, 0x05, 0x25, 0x88, 0xB9,
+ 0xB7, 0xD2, 0xBB, 0xD2, 0xDF, 0x01, 0x61, 0x99,
+ 0xEC, 0xD0, 0x6E, 0x15, 0x57, 0xCD, 0x09, 0x15,
+ 0xB3, 0x35, 0x3B, 0xBB, 0x64, 0xE0, 0xEC, 0x37,
+ 0x7F, 0xD0, 0x28, 0x37, 0x0D, 0xF9, 0x2B, 0x52,
+ 0xC7, 0x89, 0x14, 0x28, 0xCD, 0xC6, 0x7E, 0xB6,
+ 0x18, 0x4B, 0x52, 0x3D, 0x1D, 0xB2, 0x
[PATCH] test/crypto: increment dequeue timeout
Increment dequeue timeout to allow implementations taking
longer cycles.
Signed-off-by: Gowrishankar Muthukrishnan
---
app/test/test_cryptodev_asym.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 6b74dd9a73..226270556d 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -35,7 +35,7 @@
#endif
#define ASYM_TEST_MSG_LEN 256
#define TEST_VECTOR_SIZE 256
-#define DEQ_TIMEOUT 50
+#define DEQ_TIMEOUT 1
static int gbl_driver_id;
static struct crypto_testsuite_params_asym {
--
2.25.1
Re: [PATCH] rust: RFC/demo of safe API for Dpdk Eal, Eth and Rxq
Hello Harry,
I implemented a working echo server with your API.
The code is here: https://github.com/getelson-at-mellanox/rdpdk/tree/safe-q
Several changes:
*
DPDK configuration is split to 3 mandatory steps:
*
port configuration in
Port::configure(&mut self, rxq_num: u16, txq_num: u16) -> Result<(), String>
*
Rx queues configuration in
Port::config_rxqs(&mut self, desc_num: u16, mempool: DpdkMempool) -> Result<(),
String>
*
Tx queues configuration in
Port::config_txqs(&mut self, desc_num: u16) -> Result<(), String>
*
In the IO thread, I renamed the `enable_polling()` to `activate()` for Rx/Tx
symmetry.
*
I renamed `port` and `q` struct members to `port_id`, `queue_id`
Build steps:
1.
Apply
https://github.com/getelson-at-mellanox/rdpdk/blob/safe-q/dpdk-patches/0001-rust-export-missing-port-objects.patch
to DPDK source.
2.
Install DPDK
3.
Set PKG_CONFIG_PATH to DPDK installation
Activation:
# cargo run --example echo -- -a
Regards,
Gregory
From: Van Haaren, Harry
Sent: Friday, April 18, 2025 14:40
To: Gregory Etelson
Cc: dev@dpdk.org ; Richardson, Bruce
; owen.hily...@unh.edu
Subject: Re: [PATCH] rust: RFC/demo of safe API for Dpdk Eal, Eth and Rxq
External email: Use caution opening links or attachments
> From: Etelson, Gregory
> Sent: Thursday, April 17, 2025 7:58 PM
> To: Van Haaren, Harry
> Cc: dev@dpdk.org; getel...@nvidia.com; Richardson, Bruce; owen.hily...@unh.edu
> Subject: Re: [PATCH] rust: RFC/demo of safe API for Dpdk Eal, Eth and Rxq
>
> Hello Harry,
>
> Thank you for sharing the API.
> Please check out my comments below.
Thanks for reading & discussion!
> > +
> > +pub fn start(&mut self) -> (Vec, Vec) {
> > +// call rte_eth_dev_start() here, then give ownership of
> > Rxq/Txq to app
>
> After a call to Port::start, Rx and Tx queues are detached from it's port.
> With that model how rte_eth_dev_stop() and subsequent rte_eth_dev_start()
> DPDK calls can be implemented ?
Correct, the RxqHandle and TxqHandle don't have a "back reference" to the port.
There are a number of ways to ensure eth_dev_stop() cannot be called without the
Rxq/Txqs being "returned" to the Port instance first.
Eg: Use an Arc. The port instance "owns" the Arc, which means it is going
to keep
the Arc alive. Now give each Rxq/Txq a clone of this Arc. When the Drop impl
of the
Rxq/Txq runs, it will decrement the Arc. So just letting the Rxq/Txq go out
of scope
will be enough to have the Port understand that handle is now gone.
The port itself can use Arc::into_inner function[1], which returns
Option. If the
Some(T) is returned, then all instances of RxqHandle/TxqHandle have been
dropped,
meaning it is safe to eth_dev_stop(), as it is impossible to poll RXQs if
there's no Rxq :)
[1] https://doc.rust-lang.org/std/sync/struct.Arc.html#method.into_inner
// Pseudo-code here:
Dpdk::Eth::Port::stop(&mut self) -> Result<(), Error> {
let handles_dropped = self.handle_arc.into_inner(); // returns "T" if its
the only reference to the Arc
if handles_dropped.is_none() {
return Err("an Rxq or Txq handle remains alive, cannot safely stop this
port");
}
}
There's probably a few others, but that's "idiomatic Rust" solution.
We'd have to pass the Arc from the RxqHandle into the Rxq instance itself too,
but that's fine.
> > +fn main() {
> > +let mut dpdk = dpdk::Eal::init().expect("dpdk must init ok");
> > +let rx_mempool = dpdk::Mempool::new(4096);
> > +
> > +let mut ports = dpdk.take_eth_ports().expect("take eth ports ok");
>
> Eal::take_eth_ports() resets EAL ports.
I don't think it "resets" here. The "take eth ports" removes the Port instances
from
the dpdk::Eal struct, but there's no "reset" behaviour.
> A call to rte_dev_probe() will ether fail, because Eal::eth_ports is None
> or create another port-0, depending on implementation.
I don't see how or why rte_dev_probe() would be called. The idea is not to
allow Rust
apps call DPDK C APIs "when they want". The safe Rust API provides the required
abstraction.
So its not possible to have another call to rte_dev_probe(), after the 1st time
under eal_init().
Similar topic: Hotplug. I have experience with designing C APIs around hotplug
use-cases (Music/DJ software, from before my DPDK/networking days!). I think
DPDK has
an interesting "push hotplug" approach (aka, App makes a function call to
"request" the device).
Then on successful return, we can call rte_eth_dev_get_port_by_name() to get
the u16 port_id,
and build the Port instance from that. Outline API:
enum EalHotplugDev {
EthDev(Dpdk::Eth::Port), // enums can have contents in Rust :)
CryptoDev(Dpdk::Crypto),
// Etc
}
Eal::hotplug_add(bus: String, dev: String, args: String) ->
Result {
// TODO: call rte_eal_hotplug_add()
// TODO: identify how to know if its an Eth, Crypto, Dma, or other dev type?
match (dev_type) {
