Re: [PATCH] ipsec: remove unneccessary null check
On 1/13/2023 6:44 PM, Stephen Hemminger wrote:
The function rte_ring_free() accepts NULL as vaild input
like free() and other functions.
Found with null_free_check.cocci.
Fixes: 16d6ebb65d59 ("crypto/ipsec_mb: fix null checks")
Cc: kai...@intel.com
Signed-off-by: Stephen Hemminger
---
drivers/crypto/ipsec_mb/ipsec_mb_ops.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
index 71e02cd0513d..3e52f9567401 100644
--- a/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
+++ b/drivers/crypto/ipsec_mb/ipsec_mb_ops.c
@@ -139,15 +139,12 @@ int
ipsec_mb_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
{
struct ipsec_mb_qp *qp = dev->data->queue_pairs[qp_id];
- struct rte_ring *r = NULL;
if (!qp)
return 0;
if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
- r = rte_ring_lookup(qp->name);
- if (r)
- rte_ring_free(r);
+ rte_ring_free(rte_ring_lookup(qp->name));
#if IMB_VERSION(1, 1, 0) > IMB_VERSION_NUM
if (qp->mb_mgr)
Acked-by: Fan Zhang
Re: [PATCH v3 0/4] compressdev: add LZ4 support
Hi, The patchset only have library change and added performance tests. We shall have at least one PMD to support the added algorithms and unit test updated for the PMD/algorithms. Regards, Fan On 2/13/2023 6:11 AM, Michael Baum wrote: Add support for LZ4 compression algorithm for both API and app. In addition, enable app to test de/comp only. This option already exists in both app doc and arguments but isn't implemented inside the application. LZ4: https://github.com/lz4/lz4 RFC: https://patchwork.dpdk.org/project/dpdk/patch/20220410182622.8828-1-rzid...@nvidia.com/ v2: - Add macros for all LZ4 flags in the standard. - Rebase. v3: - Rebase. Michael Baum (4): compressdev: add LZ4 algorithm support app/test-compress-perf: allow test single compress operation app/test-compress-perf: add algo option app/test-compress-perf: add LZ4 support app/test-compress-perf/comp_perf_options.h| 9 +- .../comp_perf_options_parse.c | 83 +++- .../comp_perf_test_common.c | 126 +- .../comp_perf_test_cyclecount.c | 82 +++- .../comp_perf_test_throughput.c | 75 +++ .../comp_perf_test_verify.c | 75 +++ app/test-compress-perf/main.c | 63 +++-- doc/guides/compressdevs/features/default.ini | 7 + doc/guides/rel_notes/release_23_03.rst| 16 +++ doc/guides/tools/comp_perf.rst| 5 + lib/compressdev/rte_comp.c| 12 ++ lib/compressdev/rte_comp.h| 79 ++- 12 files changed, 488 insertions(+), 144 deletions(-)
Re: [PATCH v1] eventdev/crypto: wrong crypto enqueue count stats
On 11/30/2022 3:11 PM, Ganapati Kundapura wrote: crypto_enq_count is updated on failure to enqueue ops to cryptodev. Updated crypto_enq_count on successful enqueue of ops to cryptodev. Signed-off-by: Ganapati Kundapura diff --git a/lib/eventdev/rte_event_crypto_adapter.c b/lib/eventdev/rte_event_crypto_adapter.c index c293a62..e1a0367 100644 --- a/lib/eventdev/rte_event_crypto_adapter.c +++ b/lib/eventdev/rte_event_crypto_adapter.c @@ -485,6 +485,9 @@ eca_enq_to_cryptodev(struct event_crypto_adapter *adapter, struct rte_event *ev, cdev_id, qp_id, &nb_enqueued); + stats->crypto_enq_count += nb_enqueued; + n += nb_enqueued; + /** * If some crypto ops failed to flush to cdev and * space for another batch is not available, stop @@ -495,9 +498,6 @@ eca_enq_to_cryptodev(struct event_crypto_adapter *adapter, struct rte_event *ev, &qp_info->cbuf))) adapter->stop_enq_to_cryptodev = true; } - - stats->crypto_enq_count += nb_enqueued; - n += nb_enqueued; } return n; Acked-by: Fan Zhang
Re: [PATCH v1] doc: update release notes for 23.03
On 3/30/2023 5:09 PM, John McNamara wrote: Fix grammar, spelling and formatting of DPDK 23.03 release notes. Signed-off-by: John McNamara --- * Minor fixes/changes only. doc/guides/rel_notes/release_23_03.rst | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst index b93903447d..a31d34f5f5 100644 --- a/doc/guides/rel_notes/release_23_03.rst +++ b/doc/guides/rel_notes/release_23_03.rst @@ -71,7 +71,7 @@ New Features * **Added platform bus support.** A platform bus provides a way to use Linux platform devices which - are compatible with vfio-platform kernel driver. + are compatible with the do vfio-platform kernel driver. Hi John, Looks like there are a double spacing problem between "do" and "vfio-platform", also I suppose "the vfio-platform" is sufficient. Other than that, Acked-by: Fan Zhang
Re: [PATCH] test/crypto: add cryptodev reconfig test
Hi Aakash,
I really like the idea to create a test for device reconfiguration.
I am wondering if we need to test all PMDs against this patch first.
Regards,
Fan
On 4/5/2023 8:41 AM, Aakash Sasidharan wrote:
Add cryptodev tests to verify that the device supports
reconfiguration any number of times via
rte_cryptodev_configure API.
Signed-off-by: Aakash Sasidharan
---
app/test/test_cryptodev.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 9c670e9a35..3376ed91a3 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -12368,6 +12368,85 @@ test_stats(void)
return TEST_SUCCESS;
}
+static int
+test_device_reconfigure(void)
+{
+ struct crypto_testsuite_params *ts_params = &testsuite_params;
+ uint16_t orig_nb_qps = ts_params->conf.nb_queue_pairs;
+ struct rte_cryptodev_qp_conf qp_conf = {
+ .nb_descriptors = MAX_NUM_OPS_INFLIGHT,
+ .mp_session = ts_params->session_mpool
+ };
+ uint16_t qp_id, dev_id, num_devs = 0;
+
+ TEST_ASSERT((num_devs = rte_cryptodev_count()) >= 1,
+ "Need at least %d devices for test", 1);
+
+ dev_id = ts_params->valid_devs[0];
+
+ /* Stop the device in case it's started so it can be configured */
+ rte_cryptodev_stop(dev_id);
+
+ TEST_ASSERT_SUCCESS(rte_cryptodev_configure(dev_id, &ts_params->conf),
+ "Failed test for rte_cryptodev_configure: "
+ "dev_num %u", dev_id);
+
+ /* Reconfigure with same configure params */
+ TEST_ASSERT_SUCCESS(rte_cryptodev_configure(dev_id, &ts_params->conf),
+ "Failed test for rte_cryptodev_configure: "
+ "dev_num %u", dev_id);
+
+ /* Reconfigure with just one queue pair */
+ ts_params->conf.nb_queue_pairs = 1;
+
+ TEST_ASSERT_SUCCESS(rte_cryptodev_configure(ts_params->valid_devs[0],
+ &ts_params->conf),
+ "Failed to configure cryptodev: dev_id %u, qp_id %u",
+ ts_params->valid_devs[0],
ts_params->conf.nb_queue_pairs);
+
+ for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
+ TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
+ ts_params->valid_devs[0], qp_id, &qp_conf,
+ rte_cryptodev_socket_id(
+ ts_params->valid_devs[0])),
+ "Failed test for "
+ "rte_cryptodev_queue_pair_setup: num_inflights "
+ "%u on qp %u on cryptodev %u",
+ qp_conf.nb_descriptors, qp_id,
+ ts_params->valid_devs[0]);
+ }
+
+ /* Reconfigure with max number of queue pairs */
+ ts_params->conf.nb_queue_pairs = orig_nb_qps;
+
+ TEST_ASSERT_SUCCESS(rte_cryptodev_configure(ts_params->valid_devs[0],
+ &ts_params->conf),
+ "Failed to configure cryptodev: dev_id %u, qp_id %u",
+ ts_params->valid_devs[0],
ts_params->conf.nb_queue_pairs);
+
+ qp_conf.mp_session = ts_params->session_mpool;
+
+ for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
+ TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
+ ts_params->valid_devs[0], qp_id, &qp_conf,
+ rte_cryptodev_socket_id(
+ ts_params->valid_devs[0])),
+ "Failed test for "
+ "rte_cryptodev_queue_pair_setup: num_inflights "
+ "%u on qp %u on cryptodev %u",
+ qp_conf.nb_descriptors, qp_id,
+ ts_params->valid_devs[0]);
+ }
+
+ /* Start the device */
+ TEST_ASSERT_SUCCESS(rte_cryptodev_start(ts_params->valid_devs[0]),
+ "Failed to start cryptodev %u",
+ ts_params->valid_devs[0]);
+
+ /* Test expected values */
+ return test_AES_CBC_HMAC_SHA1_encrypt_digest();
+}
+
static int MD5_HMAC_create_session(struct crypto_testsuite_params *ts_params,
struct crypto_unittest_params *ut_params,
enum rte_crypto_auth_operation op,
@@ -16022,6 +16101,8 @@ static struct unit_test_suite cryptodev_gen_testsuite
= {
.suite_name = "Crypto General Unit Test Suite",
.setup = crypto_gen_testsuite_setup,
.unit_test_cases = {
+ TEST_CASE_ST(ut_setup, ut_teardown,
+ test_device_reconfigure),
TEST_CASE_ST(ut_setup, ut_teardown,
Re: [PATCH] test/crypto: add cryptodev reconfig test
On 4/5/2023 8:41 AM, Aakash Sasidharan wrote: Add cryptodev tests to verify that the device supports reconfiguration any number of times via rte_cryptodev_configure API. Signed-off-by: Aakash Sasidharan --- Acked-by: Fan Zhang
Re: [PATCH 6/6] crypto/qat: remove useless log level checks
On 6/9/2023 2:54 PM, Maxime Coquelin wrote: qat_sym_debug_log_dump() being stubbed if log level is less than debug, it is not necessary to check the log level before calling it. Signed-off-by: Maxime Coquelin --- Acked-by: Fan Zhang
Re: [PATCH 1/6] crypto/qat: fix sym device prototype
On 6/9/2023 2:54 PM, Maxime Coquelin wrote:
qat_dev_cmd_param parameter of qat_sym_dev_create() was
wrongly marked as unused, this patch fixes it.
Fixes: fb3b9f492205 ("crypto/qat: rework burst data path")
Cc: sta...@dpdk.org
Signed-off-by: Maxime Coquelin
---
drivers/crypto/qat/qat_sym.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c
index 08e92191a3..2450f042c8 100644
--- a/drivers/crypto/qat/qat_sym.c
+++ b/drivers/crypto/qat/qat_sym.c
@@ -179,7 +179,7 @@ qat_sym_dequeue_burst(void *qp, struct rte_crypto_op **ops,
int
qat_sym_dev_create(struct qat_pci_device *qat_pci_dev,
- struct qat_dev_cmd_param *qat_dev_cmd_param __rte_unused)
+ struct qat_dev_cmd_param *qat_dev_cmd_param)
{
int i = 0, ret = 0;
uint16_t slice_map = 0;
Acked-by: Fan Zhang
Re: [EXT] [dpdk-dev v5] lib/cryptodev: multi-process IPC request handler
Hi Akhil, On 06/10/2022 19:49, Akhil Goyal wrote: As some cryptode PMDs have multiprocess support, the secondary process needs queue-pair to be configured by the primary process before to use. This patch adds an IPC register function to help the primary process to register IPC action that allow secondary process to configure cryptodev queue-pair via IPC messages during the runtime. Why are we forcing user another alternate API for secondary process to work? Can we not register the IPC inside rte_cryptodev_queue_pair_setup() ? As I understand till now, You have introduced another API rte_cryptodev_mp_request_register(), Which will be called by application if primary-secondary communication is required. And if it is registered, rte_cryptodev_ipc_request() will be called from somewhere(not sure when this will be called). And the call to rte_cryptodev_queue_pair_setup() from the secondary will do nothing. Is this a correct understanding? If it is correct, then it is an unnecessary overhead for the application. We should update the rte_cryptodev_queue_pair_setup instead to handle primary and secondary configuration. IMO, you do not need to change anything in the library. Everything can be handled in the PMD. When the queue_pair_setup is called for particular qp_id, Store the getpid() of the calling process into the priv data of queue pair if it is not already configured And if configured return failure. And in case of release you can also check the same. The configuration of queues for multi process is specific to PMDs. There may be PMDs which may support same queue pair to be used by different processes. Rx queue from the qp by one process and Tx queue from the qp by another process. This will be needed if one process is doing only enqueue and the other only dequeue on the same qp. So in that case, your implementation will not work. This is a question we didn't think as comprehensive as you did. With the change Kai did at least all Intel PMDs will support that. I assume we need some feature flag to state that? After setup, a new "qp_in_used_pid" param stores the PID to provide the ownership of the queue-pair so that only the PID matched queue-pair free request is allowed in the future. qp_in_used_pid looks very cryptic, I believe this should be part of queue pair private data of PMD. Adding this in cryptodev data is not justified. This property is per queue and not per crypto device. Hence adding in device data does not make sense to me. Agreed. The PID storage is not mandatory for every PMD but only for some (ipsec-mb for example) so we should store the PID info inside the PMD queue pair data instead. Regards, Fan
Re: [PATCH v3] doc: support IPsec Multi-buffer lib v1.3
Hi Pablo, On 11/10/2022 11:07 AM, Pablo de Lara wrote: Updated AESNI MB and AESNI GCM, KASUMI, ZUC and SNOW3G PMD documentation guides with information about the latest Intel IPSec Multi-buffer library supported. Signed-off-by: Pablo de Lara Acked-by: Ciara Power --- -v3: Fixed library version from 1.2 to 1.3 in one line -v2: Removed repeated word 'the' --- This to me is a great change that formally recommending one PMD over the other for performance reason. Do you think release notes should be updated to shut out this change? Regards, Fan Other than that Acked-by: Fan Zhang
Re: [dpdk-dev v1] app/test: fix of bitwise and operator in return
On 11/11/2022 11:59 AM, Kai Ji wrote: This patch remove incorrect bitwise and operator used in the return function of sw snow3g testcase Signed-off-by: Kai Ji --- app/test/test_cryptodev.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index e1122fcd7c..d6ae762df9 100644 --- a/app/test/test_cryptodev.c +++ b/app/test/test_cryptodev.c @@ -6870,8 +6870,10 @@ test_snow3g_decryption_with_digest_test_case_1(void) */ snow3g_hash_test_vector_setup(&snow3g_test_case_7, &snow3g_hash_data); - return test_snow3g_decryption(&snow3g_test_case_7) & - test_snow3g_authentication_verify(&snow3g_hash_data); + if (test_snow3g_decryption(&snow3g_test_case_7)) + return TEST_FAILED; + + return test_snow3g_authentication_verify(&snow3g_hash_data); } static int Acked-by: Fan Zhang
Re: [dpdk-dev v5] doc: support IPsec Multi-buffer lib v1.3
Hi, On 11/15/2022 5:11 PM, Kai Ji wrote: From: Pablo de Lara Updated AESNI MB and AESNI GCM, KASUMI, ZUC, SNOW3G and CHACHA20_POLY1305 PMD documentation guides with information about the latest Intel IPSec Multi-buffer library supported. Signed-off-by: Pablo de Lara Acked-by: Ciara Power Acked-by: Brian Dooley Signed-off-by: Kai Ji --- -v5: Release notes update -v4: Added information on CHACHA20_POLY1305 PMD guide -v3: Fixed library version from 1.2 to 1.3 in one line -v2: Removed repeated word 'the' --- doc/guides/cryptodevs/aesni_gcm.rst | 8 +++--- doc/guides/cryptodevs/aesni_mb.rst | 29 - doc/guides/cryptodevs/chacha20_poly1305.rst | 12 ++--- doc/guides/cryptodevs/kasumi.rst| 15 --- doc/guides/cryptodevs/snow3g.rst| 15 --- doc/guides/cryptodevs/zuc.rst | 14 +++--- doc/guides/rel_notes/release_22_11.rst | 10 ++- 7 files changed, 76 insertions(+), 27 deletions(-) diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst index 4e55b543ef..50dcdbbbeb 100644 --- a/doc/guides/rel_notes/release_22_11.rst +++ b/doc/guides/rel_notes/release_22_11.rst @@ -240,7 +240,15 @@ New Features * **Updated ipsec_mb crypto driver.** - Added SNOW-3G and ZUC support for ARM platform. + * Added SNOW-3G and ZUC support for ARM platform. + * Added Intel IPsec MB v1.3 library support, see the following guides for +more details: +:doc:`../cryptodevs/aesni_gcm` +:doc:`../cryptodevs/aesni_mb` +:doc:`../cryptodevs/chacha20_poly1305` +:doc:`../cryptodevs/kasumi` +:doc:`../cryptodevs/snow3g` +:doc:`../cryptodevs/zuc` * **Added UADK crypto driver.** -- 2.17.1 This text, in conjunction with existing ARM news, looks confusing to me. We may have to have clearer feature descriptor for both platforms from this point. My suggestion: * **Updated ipsec_mb crypto driver.** * Added ARM64 port of ipsec-mb library support and SNOW-3G and ZUC support for ARM platform. * Added Intel IPsec MB v1.3 library support for x86 and ARM platform, see the Regards, Fan
Re: [PATCH] doc: fix max supported packet len for virtio driver
Hi Yi, Please add "Fixes: x" description to the commit message. You may find more information in https://core.dpdk.org/contribute/. Regards, Fan On 11/18/2022 1:26 AM, li...@chinatelecom.cn wrote: From: Yi Li According to VIRTIO_MAX_RX_PKTLEN macro definition, for virtio driver currently supported pkt size is 9728. Signed-off-by: Yi Li --- doc/guides/nics/virtio.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst index aace780249..c422e7347a 100644 --- a/doc/guides/nics/virtio.rst +++ b/doc/guides/nics/virtio.rst @@ -43,7 +43,7 @@ Features and Limitations of virtio PMD In this release, the virtio PMD provides the basic functionality of packet reception and transmission. * It supports merge-able buffers per packet when receiving packets and scattered buffer per packet -when transmitting packets. The packet size supported is from 64 to 1518. +when transmitting packets. The packet size supported is from 64 to 9728. * It supports multicast packets and promiscuous mode.
Re: [EXT] [dpdk-dev v6] doc: support IPsec Multi-buffer lib v1.3
Hi Akhil, From 22.11 the ipsec-mb PMDs will be working on two different libraries that may or may not work the same. We also have two different contributor groups working on adding features on top of each library, again one may or may not be compatible to another. I believe there should be some words necessary to distinguish each library support as well as the credits for adding certain features for one platform. On 11/21/2022 6:57 AM, Akhil Goyal wrote: diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst index 4e55b543ef..b98b603fe7 100644 --- a/doc/guides/rel_notes/release_22_11.rst +++ b/doc/guides/rel_notes/release_22_11.rst @@ -240,7 +240,16 @@ New Features * **Updated ipsec_mb crypto driver.** - Added SNOW-3G and ZUC support for ARM platform. + * Added ARM64 port of ipsec-mb library support and SNOW-3G and ZUC +support for ARM platform. You need not update the above line. * Added SNOW-3G and ZUC support for ARM platform. Should be good enough. + * Added Intel IPsec MB v1.3 library support for x86 platform, +see the following guides for more details: +:doc:`../cryptodevs/aesni_gcm` +:doc:`../cryptodevs/aesni_mb` +:doc:`../cryptodevs/chacha20_poly1305` +:doc:`../cryptodevs/kasumi` +:doc:`../cryptodevs/snow3g` +:doc:`../cryptodevs/zuc` I believe adding reference for each guide is not needed. * Added Intel IPsec MB v1.3 library support for x86 platform. Added details in the guides for all the drivers supported by ipsec_mb. What the guideline Pablo/Kai added here only applies for x86 as a. ARM does not support algorithms other than SNOW3G and ZUC. b. The performance guideline may not apply to ARM. Regards, Fan
Re: [EXT] [dpdk-dev v6] doc: support IPsec Multi-buffer lib v1.3
Hi Akhil, Agreed. Thanks for clarification. Regards, Fan On 11/21/2022 11:35 AM, Akhil Goyal wrote: Hi Fan, Hi Akhil, From 22.11 the ipsec-mb PMDs will be working on two different libraries that may or may not work the same. We also have two different contributor groups working on adding features on top of each library, again one may or may not be compatible to another. I believe there should be some words necessary to distinguish each library support as well as the credits for adding certain features for one platform. Ok, but release notes is not a correct place to mention that. It should be part of the respective driver documentation. On 11/21/2022 6:57 AM, Akhil Goyal wrote: diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst index 4e55b543ef..b98b603fe7 100644 --- a/doc/guides/rel_notes/release_22_11.rst +++ b/doc/guides/rel_notes/release_22_11.rst @@ -240,7 +240,16 @@ New Features * **Updated ipsec_mb crypto driver.** - Added SNOW-3G and ZUC support for ARM platform. + * Added ARM64 port of ipsec-mb library support and SNOW-3G and ZUC +support for ARM platform. You need not update the above line. * Added SNOW-3G and ZUC support for ARM platform. Should be good enough. + * Added Intel IPsec MB v1.3 library support for x86 platform, +see the following guides for more details: +:doc:`../cryptodevs/aesni_gcm` +:doc:`../cryptodevs/aesni_mb` +:doc:`../cryptodevs/chacha20_poly1305` +:doc:`../cryptodevs/kasumi` +:doc:`../cryptodevs/snow3g` +:doc:`../cryptodevs/zuc` I believe adding reference for each guide is not needed. * Added Intel IPsec MB v1.3 library support for x86 platform. Added details in the guides for all the drivers supported by ipsec_mb. What the guideline Pablo/Kai added here only applies for x86 as a. ARM does not support algorithms other than SNOW3G and ZUC. This should be distinguished in the .rst file. For release notes, above thing is sufficient. b. The performance guideline may not apply to ARM. Again, it should be part of driver documentation and not release notes. And for each of the release note bullet that I suggested are mentioning the Platform on which the support is added.
Re: [PATCH] maintainers: split baseband from crypto tree
On 12/5/2022 7:59 AM, Akhil Goyal wrote: Baseband patches are now split from dpdk-next-crypto, All baseband patches need to be submitted to dpdk-next-baseband which will be maintained by Maxime. Cc: maxime.coque...@redhat.com Signed-off-by: Akhil Goyal --- MAINTAINERS | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 22ef2ea4b9..3dc3f5b348 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -61,6 +61,10 @@ Next-eventdev Tree M: Jerin Jacob T: git://dpdk.org/next/dpdk-next-eventdev +Next-baseband Tree +M: Maxime Coquelin +T: git://dpdk.org/next/dpdk-next-baseband + Stable Branches M: Luca Boccassi M: Kevin Traynor @@ -432,7 +436,7 @@ F: app/test-pmd/cmdline_mtr.* Baseband API M: Nicolas Chautru -T: git://dpdk.org/next/dpdk-next-crypto +T: git://dpdk.org/next/dpdk-next-baseband F: lib/bbdev/ F: doc/guides/prog_guide/bbdev.rst F: doc/guides/bbdevs/features/default.ini @@ -1346,7 +1350,7 @@ Baseband Drivers Intel baseband M: Nicolas Chautru -T: git://dpdk.org/next/dpdk-next-crypto +T: git://dpdk.org/next/dpdk-next-baseband F: drivers/baseband/turbo_sw/ F: doc/guides/bbdevs/turbo_sw.rst F: doc/guides/bbdevs/features/turbo_sw.ini @@ -1365,7 +1369,7 @@ F: doc/guides/bbdevs/features/acc200.ini Null baseband M: Nicolas Chautru -T: git://dpdk.org/next/dpdk-next-crypto +T: git://dpdk.org/next/dpdk-next-baseband F: drivers/baseband/null/ F: doc/guides/bbdevs/null.rst F: doc/guides/bbdevs/features/null.ini @@ -1373,7 +1377,7 @@ F: doc/guides/bbdevs/features/null.ini NXP LA12xx M: Gagandeep Singh M: Hemant Agrawal -T: git://dpdk.org/next/dpdk-next-crypto +T: git://dpdk.org/next/dpdk-next-baseband F: drivers/baseband/la12xx/ F: doc/guides/bbdevs/la12xx.rst F: doc/guides/bbdevs/features/la12xx.ini Acked-by: Fan Zhang
Re: [PATCH] build: fix missing crypto vec limits in version
On 12/6/2022 9:23 AM, Volodymyr Fialko wrote:
Add missing function `rte_event_crypto_adapter_vector_limits_get` to
version.map.
Fixes: c1749bc5ee10 ("eventdev: introduce event cryptodev vector type")
Signed-off-by: Volodymyr Fialko
---
lib/eventdev/version.map | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
index dd63ec6f68..1a7fffd17f 100644
--- a/lib/eventdev/version.map
+++ b/lib/eventdev/version.map
@@ -20,6 +20,7 @@ DPDK_23 {
rte_event_crypto_adapter_stats_get;
rte_event_crypto_adapter_stats_reset;
rte_event_crypto_adapter_stop;
+ rte_event_crypto_adapter_vector_limits_get;
rte_event_dequeue_timeout_ticks;
rte_event_dev_attr_get;
rte_event_dev_close;
Acked-by: Fan Zhang
Re: [PATCH] cryptodev: add algo enums to string conversion APIs
On 12/12/2022 3:10 PM, Akhil Goyal wrote: Symmetric/Asymmetric algorithm strings are accessed by application using arrays in cryptodev lib, which hampers new algorithms addition in the array due to ABI breakage. These arrays are now deprecated and will be removed in next ABI break release. New APIs are added for getting the algorithm strings based on enum values. Signed-off-by: Akhil Goyal --- app/test-crypto-perf/cperf_options_parsing.c | 6 +- app/test/test_cryptodev_asym.c | 2 +- app/test/test_cryptodev_security_ipsec.c | 8 +- doc/guides/rel_notes/deprecation.rst | 7 + drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +- drivers/crypto/qat/qat_sym_session.c | 7 +- examples/l2fwd-crypto/main.c | 12 +- lib/cryptodev/cryptodev_trace_points.c | 12 ++ lib/cryptodev/rte_crypto_asym.h | 1 + lib/cryptodev/rte_crypto_sym.h | 3 + lib/cryptodev/rte_cryptodev.c| 182 ++- lib/cryptodev/rte_cryptodev.h| 52 ++ lib/cryptodev/rte_cryptodev_trace.h | 32 lib/cryptodev/version.map| 10 + 14 files changed, 309 insertions(+), 27 deletions(-) Acked-by: Fan Zhang
Re: [PATCH] crypto/qat: add SHA3 plain hash support
On 12/14/2022 4:26 PM, Ciara Power wrote: Add support for plain SHA3-224, SHA3-256, SHA3-384, and SHA3-512 hash support in QAT GEN3. Add support for SHA3-256 in GEN2. Signed-off-by: Ciara Power --- Tested using testcases from patch not yet merged. https://patchwork.dpdk.org/project/dpdk/patch/20221109152809.2026484-1-vfia...@marvell.com/ --- doc/guides/cryptodevs/features/qat.ini | 4 ++ doc/guides/cryptodevs/qat.rst| 4 ++ doc/guides/rel_notes/release_23_03.rst | 4 ++ drivers/common/qat/qat_adf/icp_qat_hw.h | 4 +- drivers/crypto/qat/dev/qat_crypto_pmd_gen2.c | 3 + drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c | 12 drivers/crypto/qat/qat_sym_session.c | 60 7 files changed, 89 insertions(+), 2 deletions(-) Acked-by: Fan Zhang
Re: questions about crypto_scheduler
Hi Zhangfei, The crypto scheduler PMD's session contains "sub-sessions" for all works, 1 sub-session per driver ID, to minimize the memory footprint. When configuring session, it configures the sub-sessions one by one. Since your UADK devices sharing the same driver ID, the crypto scheduler will only create one session for them to share. Hope this answers your question. Regards, Fan On 12/16/2022 6:54 AM, Zhangfei Gao wrote: Hi, Akhil Excuse me for the question. I am testing UADK crypto performance with dpdk-test-crypto-perf, and want to use multi-thread or multi-session for better performance, so trying to use crypto_scheduler. CMD like sudo dpdk-test-crypto-perf -l 1,2 --vdev "crypto_uadk0" --vdev "crypto_uadk1" --vdev "crypto_scheduler,worker=crypto_uadk0,worker=crypto_uadk1,mode=round-robin" -- --devtype crypto_scheduler --optype cipher-only --buffer-sz 8192 Though multi-worker is set but found it is just using one worker. Since uadk_cryptodev_probe gets the same dev->driver_id = uadk_cryptodev_driver_id in multi-probe. Then scheduler_pmd_sym_session_configure will treat only one worker, and call rte_cryptodev_sym_session_create only once. if (configured_sess[j].driver_id == worker->driver_id) break Do I misuse the crypto_scheduler for the multi-thread or multi-session. Thanks in advance.
Re: questions about crypto_scheduler
Hi Zhangfei, The crypto scheduler PMD's session contains "sub-sessions" for all works, 1 sub-session per driver ID, to minimize the memory footprint. When configuring session, it configures the sub-sessions one by one. Since your UADK devices sharing the same driver ID, the crypto scheduler will only create one session for them to share. Hope this answers your question. Regards, Fan On 12/16/2022 6:54 AM, Zhangfei Gao wrote: Hi, Akhil Excuse me for the question. I am testing UADK crypto performance with dpdk-test-crypto-perf, and want to use multi-thread or multi-session for better performance, so trying to use crypto_scheduler. CMD like sudo dpdk-test-crypto-perf -l 1,2 --vdev "crypto_uadk0" --vdev "crypto_uadk1" --vdev "crypto_scheduler,worker=crypto_uadk0,worker=crypto_uadk1,mode=round-robin" -- --devtype crypto_scheduler --optype cipher-only --buffer-sz 8192 Though multi-worker is set but found it is just using one worker. Since uadk_cryptodev_probe gets the same dev->driver_id = uadk_cryptodev_driver_id in multi-probe. Then scheduler_pmd_sym_session_configure will treat only one worker, and call rte_cryptodev_sym_session_create only once. if (configured_sess[j].driver_id == worker->driver_id) break Do I misuse the crypto_scheduler for the multi-thread or multi-session. Thanks in advance.
Re: [PATCH] test/crypto: add further ZUC testcases
Hi Ciara,
On 12/21/2022 2:04 PM, Ciara Power wrote:
Previously no ZUC decryption only or hash verify testcases existed,
only encryption and authentication.
This commit adds testcases for ZUC 128 and 256 decryption,
and hash verify.
+ if (direction == RTE_CRYPTO_CIPHER_OP_ENCRYPT) {
+ } else {
+ if (ut_params->obuf)
+ plaintext = rte_pktmbuf_mtod(ut_params->obuf, uint8_t
*);
+ else
+ plaintext = ciphertext;
+
+ debug_hexdump(stdout, "plaintext:", plaintext, ciphertext_len);
+
The below line looks a bit off: bits len = bytes len * 8 right?
+ const uint8_t *reference_plaintext = tdata->plaintext.data +
+ (tdata->validCipherOffsetInBits.len);
+
+ /* Validate obuf */
+ TEST_ASSERT_BUFFERS_ARE_EQUAL_BIT(
+ plaintext,
+ reference_plaintext,
+ tdata->validCipherLenInBits.len,
+ "ZUC Plaintext data not as expected");
static int
-test_zuc_encryption_sgl(const struct wireless_test_data *tdata)
+test_zuc_cipher_sgl(const struct wireless_test_data *tdata,
+ enum rte_crypto_cipher_operation direction)
{
struct crypto_testsuite_params *ts_params = &testsuite_params;
struct crypto_unittest_params *ut_params = &unittest_params;
int retval;
- unsigned int plaintext_pad_len;
- unsigned int plaintext_len;
- const uint8_t *ciphertext;
- uint8_t ciphertext_buffer[2048];
+ unsigned int plaintext_pad_len, ciphertext_pad_len;
+ unsigned int plaintext_len, ciphertext_len;
+ const uint8_t *ciphertext, *plaintext;
Just a piece of advice: Instead of allocating 2 buffers and we may use
only one in either direction,
we may use
uint8_t buffers[2048];
uint8_t *ciphertext_buffer = NULL, *plaintext_buffer = NULL;
And pointing either ciphertext_buffer or plaintext_buffer to buffers
based on the direction value?
+ uint8_t ciphertext_buffer[2048], plaintext_buffer[2048];
struct rte_cryptodev_info dev_info;
/* Check if device supports ZUC EEA3 */
@@ -6074,21 +6110,36 @@ test_zuc_encryption_sgl(const struct wireless_test_data
*tdata)
return TEST_SKIPPED;
}
- plaintext_len = ceil_byte_length(tdata->plaintext.len);
+ if (direction == RTE_CRYPTO_CIPHER_OP_ENCRYPT) {
+ plaintext_len = ceil_byte_length(tdata->plaintext.len);
- /* Append data which is padded to a multiple */
- /* of the algorithms block size */
- plaintext_pad_len = RTE_ALIGN_CEIL(plaintext_len, 8);
+ /* Append data which is padded to a multiple */
+ /* of the algorithms block size */
+ plaintext_pad_len = RTE_ALIGN_CEIL(plaintext_len, 8);
- ut_params->ibuf = create_segmented_mbuf(ts_params->mbuf_pool,
- plaintext_pad_len, 10, 0);
+ ut_params->ibuf = create_segmented_mbuf(ts_params->mbuf_pool,
+ plaintext_pad_len, 10, 0);
- pktmbuf_write(ut_params->ibuf, 0, plaintext_len,
- tdata->plaintext.data);
+ pktmbuf_write(ut_params->ibuf, 0, plaintext_len,
+ tdata->plaintext.data);
+ } else {
+ ciphertext_len = ceil_byte_length(tdata->ciphertext.len);
+
+ /* Append data which is padded to a multiple */
+ /* of the algorithms block size */
+ ciphertext_pad_len = RTE_ALIGN_CEIL(ciphertext_len, 8);
+
+ ut_params->ibuf = create_segmented_mbuf(ts_params->mbuf_pool,
+ ciphertext_pad_len, 10, 0);
+
+ pktmbuf_write(ut_params->ibuf, 0, ciphertext_len,
+ tdata->ciphertext.data);
+
+ }
/* Create ZUC session */
retval = create_wireless_algo_cipher_session(ts_params->valid_devs[0],
- RTE_CRYPTO_CIPHER_OP_ENCRYPT,
+ direction,
RTE_CRYPTO_CIPHER_ZUC_EEA3,
tdata->key.data, tdata->key.len,
tdata->cipher_iv.len);
@@ -6096,8 +6147,10 @@ test_zuc_encryption_sgl(const struct wireless_test_data
*tdata)
return retval;
/* Clear mbuf payload */
-
- pktmbuf_write(ut_params->ibuf, 0, plaintext_len, tdata->plaintext.data);
+ if (direction == RTE_CRYPTO_CIPHER_OP_ENCRYPT)
+ pktmbuf_write(ut_params->ibuf, 0, plaintext_len,
tdata->plaintext.data);
+ else
+ pktmbuf_write(ut_params->ibuf, 0, ciphertext_len,
tdata->ciphertext.data);
/* Create ZUC operation */
retval = create_wireless_algo_cipher_operation(tdata->cipher_iv.data,
@@ -6115,28 +6168,48 @@ test_zuc_encryption_sgl(const struct wireless_test_data
Re: [PATCH] cryptodev: increase default max nb queue pairs
On 1/4/2023 7:30 AM, Anoob Joseph wrote:
Increase default maximum number of queue pairs to 64. For sw crypto
PMDs, the number of queue pairs can be increased as required. The
default value (which is set to 8), prevents usage of sw cryptodev PMDs
with larger number of cores.
Application would be allowed to specify the number of queue pairs it
wishes to use. Only the upper bound is changed from 8 to 64.
Allow PMDs such as crypto_armv8 to run on larger number of cores.
Signed-off-by: Anoob Joseph
---
lib/cryptodev/cryptodev_pmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 0020102eb7..913a8f3623 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -29,7 +29,7 @@ extern "C" {
#include "rte_cryptodev.h"
-#define RTE_CRYPTODEV_PMD_DEFAULT_MAX_NB_QUEUE_PAIRS 8
+#define RTE_CRYPTODEV_PMD_DEFAULT_MAX_NB_QUEUE_PAIRS 64
#define RTE_CRYPTODEV_PMD_NAME_ARG ("name")
#define RTE_CRYPTODEV_PMD_MAX_NB_QP_ARG
("max_nb_queue_pairs")
Acked-by: Fan Zhang
Re: [PATCH] net/cnxk: fix deadlock in security session creation
On 1/5/2023 1:57 PM, David Marchand wrote:
Releasing the lock was missing in this branch.
Fixes: 4440eb88ddfc ("net/cnxk: use full context IPsec structures")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
drivers/net/cnxk/cn9k_ethdev_sec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/cnxk/cn9k_ethdev_sec.c
b/drivers/net/cnxk/cn9k_ethdev_sec.c
index 67966a4e49..327f221e38 100644
--- a/drivers/net/cnxk/cn9k_ethdev_sec.c
+++ b/drivers/net/cnxk/cn9k_ethdev_sec.c
@@ -556,6 +556,7 @@ cn9k_eth_sec_session_create(void *device,
if (!dev->outb.lf_base) {
plt_err("Could not allocate security session private data");
+ rte_spinlock_unlock(lock);
return -ENOMEM;
}
Acked-by: Fan Zhang
Re: [PATCH] net/ena: fix deadlock in RSS reta update
On 1/5/2023 1:57 PM, David Marchand wrote:
Add missing lock release in case of internal failure.
Fixes: e3595539e0e0 ("net/ena: proxy AQ calls to primary process")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
drivers/net/ena/ena_rss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ena/ena_rss.c b/drivers/net/ena/ena_rss.c
index b682d01c20..d0ba9d5c0a 100644
--- a/drivers/net/ena/ena_rss.c
+++ b/drivers/net/ena/ena_rss.c
@@ -105,6 +105,7 @@ int ena_rss_reta_update(struct rte_eth_dev *dev,
if (unlikely(rc != 0)) {
PMD_DRV_LOG(ERR,
"Cannot fill indirection table\n");
+ rte_spinlock_unlock(&adapter->admin_lock);
return rc;
}
}
Acked-by: Fan Zhang
Re: [PATCH] test/crypto: fix and improve ZUC cipher and auth tests
On 1/6/2023 4:15 PM, Ciara Power wrote:
The incorrect value was used for the reference plaintext offset
in ZUC cipher function. This is now fixed to convert to byte length,
rather than bits.
Also, to cleanup the ZUC test code, some small improvements are made.
The authentication function takes the auth op enum as a parameter
instead of a new variable, this can then be used directly.
The cipher SGL function does not need to buffers allocated for
ciphertext and plaintext, one can be used for both.
Fixes: be8e5d957366 ("test/crypto: add further ZUC testcases")
Signed-off-by: Ciara Power
Acked-by: Fan Zhang
Re: [PATCH] crypto/virtio: add request check on request side
On 5/23/2025 3:04 PM, Radu Nicolau wrote:
Add same request checks on the request side.
Fixes: b2866f473369 ("vhost/crypto: fix missed request check for copy mode")
Cc:roy.fan.zh...@intel.com
Cc:sta...@dpdk.org
Signed-off-by: Radu Nicolau
---
Acked-by: Fan Zhang
