[PATCH v2] net/mlx5: fix single not inline packet elts storing
The mlx5 PMD can inline packet data into transmitting descriptor (WQE)
and free mbuf immediately as data no longer needed, for non-inline
packets the mbuf pointer should be stored in elts array for coming
freeing on send completion. There was an optimization on storing
pointers in batch and there was missed storing mbuf for single
packet if non-inline was explicitly requested by flag.
Fixes: cacb44a09962 ("net/mlx5: add no-inline Tx flag")
Cc: sta...@dpdk.org
Signed-off-by: Viacheslav Ovsiienko
---
v2: "Fixes tag" added
drivers/net/mlx5/mlx5_tx.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_tx.h b/drivers/net/mlx5/mlx5_tx.h
index 20776919c2..c65031ed3b 100644
--- a/drivers/net/mlx5/mlx5_tx.h
+++ b/drivers/net/mlx5/mlx5_tx.h
@@ -3314,7 +3314,9 @@ mlx5_tx_burst_single_send(struct mlx5_txq_data
*__rte_restrict txq,
* if no inlining is configured, this is done
* by calling routine in a batch copy.
*/
- MLX5_ASSERT(!MLX5_TXOFF_CONFIG(INLINE));
+ if (MLX5_TXOFF_CONFIG(INLINE))
+ txq->elts[txq->elts_head++ & txq->elts_m] =
+ loc->mbuf;
--loc->elts_free;
#ifdef MLX5_PMD_SOFT_COUNTERS
/* Update sent data bytes counter. */
--
2.18.1
[PATCH 0/4] cryptodev: add SM3 and SM4 algorithms
ShangMi 4 (SM4) is a block cipher used in the Chinese National Standard for Wireless LAN WAPI and also used with Transport Layer Security. ShangMi 3 (SM3) is a cryptographic hash function used in the Chinese National Standard. This patcheset adds both to the Cryptodev. Arek Kusztal (4): cryptodev: add SM4 encryption algorithm cryptodev: add SM3 hash algorithm crypto/qat: add SM4 encryption algorithm crypto/qat : add SM3 hash algorithm doc/guides/cryptodevs/features/default.ini | 4 doc/guides/cryptodevs/features/qat.ini | 4 doc/guides/rel_notes/release_22_11.rst | 16 ++ drivers/common/qat/qat_adf/icp_qat_hw.h | 2 +- drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c | 9 drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c | 9 drivers/crypto/qat/qat_sym_session.c | 32 +++- lib/cryptodev/rte_crypto_sym.h | 13 +-- lib/cryptodev/rte_cryptodev.c| 8 +-- 9 files changed, 91 insertions(+), 6 deletions(-) -- 2.13.6
[PATCH 1/4] cryptodev: add SM4 encryption algorithm
SM4 is a block cipher used in the Chinese National Standard for
Wireless LAN WAPI and also used with Transport Layer Security.
- Added SM4 encryption algorithm.
Supported modes are ECB, CBC and CTR.
Signed-off-by: Arek Kusztal
---
doc/guides/cryptodevs/features/default.ini | 3 +++
doc/guides/rel_notes/release_22_11.rst | 4
lib/cryptodev/rte_crypto_sym.h | 9 -
lib/cryptodev/rte_cryptodev.c | 5 -
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/doc/guides/cryptodevs/features/default.ini
b/doc/guides/cryptodevs/features/default.ini
index 7371ca6644..1608426b12 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -61,6 +61,9 @@ DES DOCSIS BPI =
SNOW3G UEA2=
KASUMI F8 =
ZUC EEA3 =
+SM4 ECB=
+SM4 CBC=
+SM4 CTR=
;
; Supported authentication algorithms of a default crypto driver.
diff --git a/doc/guides/rel_notes/release_22_11.rst
b/doc/guides/rel_notes/release_22_11.rst
index 8c021cf050..15fc6ec40a 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -55,6 +55,10 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Added SM4 encryption algorithm in ECB, CBC and CTR mode.**
+
+ Added SM4 encryption algorithm to the Cryptodev API.
+ Supported modes are ECB, CBC and CTR.
Removed Items
-
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index daa090b978..33420e0b36 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -160,12 +160,19 @@ enum rte_crypto_cipher_algorithm {
* for m_src and m_dst in the rte_crypto_sym_op must be NULL.
*/
- RTE_CRYPTO_CIPHER_DES_DOCSISBPI
+ RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
/**< DES algorithm using modes required by
* DOCSIS Baseline Privacy Plus Spec.
* Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
* for m_src and m_dst in the rte_crypto_sym_op must be NULL.
*/
+
+ RTE_CRYPTO_CIPHER_SM4_ECB,
+ /**< SM4 algorithm in ECB mode */
+ RTE_CRYPTO_CIPHER_SM4_CBC,
+ /**< SM4 algorithm in CBC mode */
+ RTE_CRYPTO_CIPHER_SM4_CTR
+ /**< SM4 algorithm in CTR mode */
};
/** Cipher algorithm name strings */
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 42f3221052..266804f0fe 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -89,7 +89,10 @@ rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_KASUMI_F8] = "kasumi-f8",
[RTE_CRYPTO_CIPHER_SNOW3G_UEA2] = "snow3g-uea2",
- [RTE_CRYPTO_CIPHER_ZUC_EEA3]= "zuc-eea3"
+ [RTE_CRYPTO_CIPHER_ZUC_EEA3]= "zuc-eea3",
+ [RTE_CRYPTO_CIPHER_SM4_ECB] = "sm4-ecb",
+ [RTE_CRYPTO_CIPHER_SM4_CBC] = "sm4-cbc",
+ [RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
};
/**
--
2.13.6
[PATCH 2/4] cryptodev: add SM3 hash algorithm
SM3 is a cryptographic hash function used in
the Chinese National Standard.
- Added SM3 algorithm
Signed-off-by: Arek Kusztal
---
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/rel_notes/release_22_11.rst | 5 +
lib/cryptodev/rte_crypto_sym.h | 4 +++-
lib/cryptodev/rte_cryptodev.c | 3 ++-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/doc/guides/cryptodevs/features/default.ini
b/doc/guides/cryptodevs/features/default.ini
index 1608426b12..d51d80ff80 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -98,6 +98,7 @@ SHA3_384=
SHA3_384 HMAC =
SHA3_512=
SHA3_512 HMAC =
+SM3 =
;
; Supported AEAD algorithms of a default crypto driver.
diff --git a/doc/guides/rel_notes/release_22_11.rst
b/doc/guides/rel_notes/release_22_11.rst
index 15fc6ec40a..0609652b07 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -60,6 +60,11 @@ New Features
Added SM4 encryption algorithm to the Cryptodev API.
Supported modes are ECB, CBC and CTR.
+* **Added SM3 hash algorithm.**
+
+ Added SM3 hash algorithm to the Cryptodev API.
+
+
Removed Items
-
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33420e0b36..1b07e832c3 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -370,8 +370,10 @@ enum rte_crypto_auth_algorithm {
/**< HMAC using 384 bit SHA3 algorithm. */
RTE_CRYPTO_AUTH_SHA3_512,
/**< 512 bit SHA3 algorithm. */
- RTE_CRYPTO_AUTH_SHA3_512_HMAC
+ RTE_CRYPTO_AUTH_SHA3_512_HMAC,
/**< HMAC using 512 bit SHA3 algorithm. */
+ RTE_CRYPTO_AUTH_SM3
+ /**< SM3 algorithm */
};
/** Authentication algorithm name strings */
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 266804f0fe..2b6c7de930 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -135,7 +135,8 @@ rte_crypto_auth_algorithm_strings[] = {
[RTE_CRYPTO_AUTH_KASUMI_F9] = "kasumi-f9",
[RTE_CRYPTO_AUTH_SNOW3G_UIA2] = "snow3g-uia2",
- [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3"
+ [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3",
+ [RTE_CRYPTO_AUTH_SM3] = "zuc-sm3"
};
/**
--
2.13.6
[PATCH 3/4] crypto/qat: add SM4 encryption algorithm
- Added SM4 encryption algorithms.
Supported modes: ECB, CBC, CTR.
Signed-off-by: Arek Kusztal
---
doc/guides/cryptodevs/features/qat.ini | 3 +++
doc/guides/rel_notes/release_22_11.rst | 4
drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c | 9 +
drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c | 9 +
drivers/crypto/qat/qat_sym_session.c | 12
5 files changed, 37 insertions(+)
diff --git a/doc/guides/cryptodevs/features/qat.ini
b/doc/guides/cryptodevs/features/qat.ini
index b9755a757e..edabc030d7 100644
--- a/doc/guides/cryptodevs/features/qat.ini
+++ b/doc/guides/cryptodevs/features/qat.ini
@@ -40,6 +40,9 @@ KASUMI F8 = Y
AES DOCSIS BPI = Y
DES DOCSIS BPI = Y
ZUC EEA3 = Y
+SM4 ECB= Y
+SM4 CBC= Y
+SM4 CTR= Y
;
; Supported authentication algorithms of the 'qat' crypto driver.
;
diff --git a/doc/guides/rel_notes/release_22_11.rst
b/doc/guides/rel_notes/release_22_11.rst
index 0609652b07..c6638ded82 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -64,6 +64,10 @@ New Features
Added SM3 hash algorithm to the Cryptodev API.
+* **Updated the Intel QuickAssist Technology (QAT) symmetric crypto PMD.**
+
+ Added SM4 encryption algorithm to the QAT PMD.
+ Supported modes are ECB, CBC and CTR.
Removed Items
-
diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
b/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
index 2d5f10aeac..d1285cdbd4 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gen3.c
@@ -131,6 +131,15 @@ static struct rte_cryptodev_capabilities
qat_sym_crypto_caps_gen3[] = {
CAP_RNG(key_size, 32, 32, 0),
CAP_RNG(digest_size, 16, 16, 0),
CAP_RNG(aad_size, 0, 240, 1), CAP_RNG(iv_size, 12, 12, 0)),
+ QAT_SYM_CIPHER_CAP(SM4_ECB,
+ CAP_SET(block_size, 16),
+ CAP_RNG(key_size, 16, 16, 0), CAP_RNG(iv_size, 0, 0, 0)),
+ QAT_SYM_CIPHER_CAP(SM4_CBC,
+ CAP_SET(block_size, 16),
+ CAP_RNG(key_size, 16, 16, 0), CAP_RNG(iv_size, 16, 16, 0)),
+ QAT_SYM_CIPHER_CAP(SM4_CTR,
+ CAP_SET(block_size, 16),
+ CAP_RNG(key_size, 16, 16, 0), CAP_RNG(iv_size, 16, 16, 0)),
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
};
diff --git a/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
b/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
index a9457d9278..efbbbda4b6 100644
--- a/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
+++ b/drivers/crypto/qat/dev/qat_crypto_pmd_gen4.c
@@ -91,6 +91,15 @@ static struct rte_cryptodev_capabilities
qat_sym_crypto_caps_gen4[] = {
CAP_RNG(key_size, 32, 32, 0),
CAP_RNG(digest_size, 16, 16, 0),
CAP_RNG(aad_size, 0, 240, 1), CAP_RNG(iv_size, 12, 12, 0)),
+ QAT_SYM_CIPHER_CAP(SM4_ECB,
+ CAP_SET(block_size, 16),
+ CAP_RNG(key_size, 16, 16, 0), CAP_RNG(iv_size, 0, 0, 0)),
+ QAT_SYM_CIPHER_CAP(SM4_CBC,
+ CAP_SET(block_size, 16),
+ CAP_RNG(key_size, 16, 16, 0), CAP_RNG(iv_size, 16, 16, 0)),
+ QAT_SYM_CIPHER_CAP(SM4_CTR,
+ CAP_SET(block_size, 16),
+ CAP_RNG(key_size, 16, 16, 0), CAP_RNG(iv_size, 16, 16, 0)),
RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
};
diff --git a/drivers/crypto/qat/qat_sym_session.c
b/drivers/crypto/qat/qat_sym_session.c
index b30396487e..f4e0faa8e1 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -432,6 +432,18 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
}
session->qat_mode = ICP_QAT_HW_CIPHER_XTS_MODE;
break;
+ case RTE_CRYPTO_CIPHER_SM4_ECB:
+ session->qat_cipher_alg = ICP_QAT_HW_CIPHER_ALGO_SM4;
+ session->qat_mode = ICP_QAT_HW_CIPHER_ECB_MODE;
+ break;
+ case RTE_CRYPTO_CIPHER_SM4_CBC:
+ session->qat_cipher_alg = ICP_QAT_HW_CIPHER_ALGO_SM4;
+ session->qat_mode = ICP_QAT_HW_CIPHER_CBC_MODE;
+ break;
+ case RTE_CRYPTO_CIPHER_SM4_CTR:
+ session->qat_cipher_alg = ICP_QAT_HW_CIPHER_ALGO_SM4;
+ session->qat_mode = ICP_QAT_HW_CIPHER_CTR_MODE;
+ break;
case RTE_CRYPTO_CIPHER_3DES_ECB:
case RTE_CRYPTO_CIPHER_AES_ECB:
case RTE_CRYPTO_CIPHER_AES_F8:
--
2.13.6
[PATCH 4/4] crypto/qat : add SM3 hash algorithm
- Added SM3 hash algorithm.
Signed-off-by: Arek Kusztal
---
doc/guides/cryptodevs/features/qat.ini | 1 +
doc/guides/rel_notes/release_22_11.rst | 3 +++
drivers/common/qat/qat_adf/icp_qat_hw.h | 2 +-
drivers/crypto/qat/qat_sym_session.c| 20 +++-
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/doc/guides/cryptodevs/features/qat.ini
b/doc/guides/cryptodevs/features/qat.ini
index edabc030d7..4508becc56 100644
--- a/doc/guides/cryptodevs/features/qat.ini
+++ b/doc/guides/cryptodevs/features/qat.ini
@@ -65,6 +65,7 @@ KASUMI F9= Y
AES XCBC MAC = Y
ZUC EIA3 = Y
AES CMAC (128) = Y
+SM3 = Y
;
; Supported AEAD algorithms of the 'qat' crypto driver.
diff --git a/doc/guides/rel_notes/release_22_11.rst
b/doc/guides/rel_notes/release_22_11.rst
index c6638ded82..5fb79f741c 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -69,6 +69,9 @@ New Features
Added SM4 encryption algorithm to the QAT PMD.
Supported modes are ECB, CBC and CTR.
+ Added SM3 hash algorithm to the QAT PMD.
+
+
Removed Items
-
diff --git a/drivers/common/qat/qat_adf/icp_qat_hw.h
b/drivers/common/qat/qat_adf/icp_qat_hw.h
index b1e6a1fa15..f6875b5242 100644
--- a/drivers/common/qat/qat_adf/icp_qat_hw.h
+++ b/drivers/common/qat/qat_adf/icp_qat_hw.h
@@ -46,7 +46,7 @@ enum icp_qat_hw_auth_algo {
ICP_QAT_HW_AUTH_ALGO_KASUMI_F9 = 12,
ICP_QAT_HW_AUTH_ALGO_SNOW_3G_UIA2 = 13,
ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3 = 14,
- ICP_QAT_HW_AUTH_RESERVED_1 = 15,
+ ICP_QAT_HW_AUTH_ALGO_SM3 = 15,
ICP_QAT_HW_AUTH_RESERVED_2 = 16,
ICP_QAT_HW_AUTH_ALGO_SHA3_256 = 17,
ICP_QAT_HW_AUTH_RESERVED_3 = 18,
diff --git a/drivers/crypto/qat/qat_sym_session.c
b/drivers/crypto/qat/qat_sym_session.c
index f4e0faa8e1..6996c3499b 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -687,6 +687,10 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
session->digest_length = auth_xform->digest_length;
switch (auth_xform->algo) {
+ case RTE_CRYPTO_AUTH_SM3:
+ session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_SM3;
+ session->auth_mode = ICP_QAT_HW_AUTH_MODE2;
+ break;
case RTE_CRYPTO_AUTH_SHA1:
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_SHA1;
session->auth_mode = ICP_QAT_HW_AUTH_MODE0;
@@ -1092,6 +1096,8 @@ static int qat_hash_get_block_size(enum
icp_qat_hw_auth_algo qat_hash_alg)
return ICP_QAT_HW_AES_BLK_SZ;
case ICP_QAT_HW_AUTH_ALGO_MD5:
return MD5_CBLOCK;
+ case ICP_QAT_HW_AUTH_ALGO_SM3:
+ return 64;
case ICP_QAT_HW_AUTH_ALGO_DELIMITER:
/* return maximum block size in this case */
return SHA512_CBLOCK;
@@ -2035,7 +2041,7 @@ int qat_sym_cd_auth_set(struct qat_sym_session *cdesc,
|| cdesc->is_cnt_zero
)
hash->auth_counter.counter = 0;
- else {
+ else if (cdesc->auth_mode == ICP_QAT_HW_AUTH_MODE1) {
int block_size = qat_hash_get_block_size(cdesc->qat_hash_alg);
if (block_size < 0)
@@ -2048,7 +2054,19 @@ int qat_sym_cd_auth_set(struct qat_sym_session *cdesc,
/*
* cd_cur_ptr now points at the state1 information.
*/
+ uint8_t state1[] = {
+ 0x73, 0x80, 0x16, 0x6f, 0x49, 0x14, 0xb2, 0xb9,
+ 0x17, 0x24, 0x42, 0xd7, 0xda, 0x8a, 0x06, 0x00,
+ 0xa9, 0x6f, 0x30, 0xbc, 0x16, 0x31, 0x38, 0xaa,
+ 0xe3, 0x8d, 0xee, 0x4d, 0xb0, 0xfb, 0x0e, 0x4e
+ };
switch (cdesc->qat_hash_alg) {
+ case ICP_QAT_HW_AUTH_ALGO_SM3:
+ rte_memcpy(cdesc->cd_cur_ptr, state1,
+ sizeof(state1));
+ state1_size = 32;
+ state2_size = 32;
+ break;
case ICP_QAT_HW_AUTH_ALGO_SHA1:
if (cdesc->auth_mode == ICP_QAT_HW_AUTH_MODE0) {
/* Plain SHA-1 */
--
2.13.6
RE: [PATCH] net/mlx5: fix matcher priority for esp item
> -Original Message-
> From: Bassam Zaid AlKilani
> Sent: Thursday, July 28, 2022 17:12
> To: dev@dpdk.org
> Cc: Raslan Darawsheh ; rzid...@nvidia.com;
> sta...@dpdk.org; Matan Azrad ; Slava Ovsiienko
>
> Subject: [PATCH] net/mlx5: fix matcher priority for esp item
>
> ESP is one of IPSec protocols over both IPv4 and IPv6 and is considered a
> tunnel layer that cannot be followed by any other layer. Taking that into
> consideration, esp is considered as a 4 layer.
>
> Not defining ESP's priority will make it match with the same priority as its
> prior IP layer, which has a layer 3 priority. This will lead to issues in
> matching and will match the packet with the first matching rule even if it
> doesn't have an esp layer in its pattern, disregarding any following rules
> that could have an esp item and can be actually a more accurate match since
> it will have a longer matching criterion.
>
> This is fixed by defining the priority for the ESP item to have a layer 4
> priority, making the match be for the rule with the more accurate and longer
> matching criteria.
>
> Fixes: 18ca4a4ec73a ("net/mlx5: support ESP SPI match and RSS hash")
> Cc: rzid...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bassam ZaidAlKilani
Acked-by: Viacheslav Ovsiienko
mlx5_common failed errno=121
Hello, I am trying to run p4-dpdk-target (https://github.com/p4lang/p4-dpdk-target), with DPDK version 22.07.0-rc2 (the one provided by the p4-dpdk-target). However, when I run the bf_switchd I get the following error, by the dpdk driver: """ mlx5_common: DevX read access NIC register=0X9055 failed errno=121 status=0x3 syndrome=0x54e3a9 mlx5_common: DevX create q counter set failed errno=121 status=0x2 syndrome=0x8975f1 """ The same error appears when running dpdk-testpmd (by the above DPDK version). The NIC is an NVIDIA/ Mellanox Connect-X 5. I have also tested with DPDK version 21.11.0 and it doesn't show this error and works correctly. Do you have any suggestions on what that particular error might be and how to fix it? It seems like it tries to read a wrong register, but I am not sure. Thank you for your help. Best Regards, Panagiotis Famelis.
[PATCH 0/3] crypto/qat: extend asymmetric crypto pmd
This patchset extends Intel QuickAssist Technology asymmetric crypto PMD. Following features were added: - ECDH algorithm handling - EC point verification Arek Kusztal (3): crypto/qat: make immutable parameters constant crypto/qat: add ecdh key exchange algorithm crypto/qat: add ecdh public key verification drivers/common/qat/qat_adf/qat_pke.h | 40 - drivers/crypto/qat/qat_asym.c| 283 +++ drivers/crypto/qat/qat_ec.h | 2 +- 3 files changed, 250 insertions(+), 75 deletions(-) -- 2.13.6
[PATCH 1/3] crypto/qat: make immutable parameters constant
All pointers passed to functions that are not supposed
to have its data changed should be marked as constant.
Additionally session field should be checked only in
with session case.
Signed-off-by: Arek Kusztal
---
drivers/common/qat/qat_adf/qat_pke.h | 16 ++---
drivers/crypto/qat/qat_asym.c| 133 ++-
drivers/crypto/qat/qat_ec.h | 2 +-
3 files changed, 76 insertions(+), 75 deletions(-)
diff --git a/drivers/common/qat/qat_adf/qat_pke.h
b/drivers/common/qat/qat_adf/qat_pke.h
index 6c12bfd989..00e2b776dc 100644
--- a/drivers/common/qat/qat_adf/qat_pke.h
+++ b/drivers/common/qat/qat_adf/qat_pke.h
@@ -50,13 +50,13 @@ get_modexp_function2(uint32_t bytesize)
}
static struct qat_asym_function
-get_modexp_function(struct rte_crypto_asym_xform *xform)
+get_modexp_function(const struct rte_crypto_asym_xform *xform)
{
return get_modexp_function2(xform->modex.modulus.length);
}
static struct qat_asym_function
-get_modinv_function(struct rte_crypto_asym_xform *xform)
+get_modinv_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function = { };
@@ -137,7 +137,7 @@ get_modinv_function(struct rte_crypto_asym_xform *xform)
}
static struct qat_asym_function
-get_rsa_enc_function(struct rte_crypto_asym_xform *xform)
+get_rsa_enc_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function = { };
@@ -164,7 +164,7 @@ get_rsa_enc_function(struct rte_crypto_asym_xform *xform)
}
static struct qat_asym_function
-get_rsa_dec_function(struct rte_crypto_asym_xform *xform)
+get_rsa_dec_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function = { };
@@ -191,7 +191,7 @@ get_rsa_dec_function(struct rte_crypto_asym_xform *xform)
}
static struct qat_asym_function
-get_rsa_crt_function(struct rte_crypto_asym_xform *xform)
+get_rsa_crt_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function = { };
int nlen = xform->rsa.qt.p.length * 2;
@@ -219,7 +219,7 @@ get_rsa_crt_function(struct rte_crypto_asym_xform *xform)
}
static struct qat_asym_function
-get_ecdsa_verify_function(struct rte_crypto_asym_xform *xform)
+get_ecdsa_verify_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function;
@@ -243,7 +243,7 @@ get_ecdsa_verify_function(struct rte_crypto_asym_xform
*xform)
}
static struct qat_asym_function
-get_ecdsa_function(struct rte_crypto_asym_xform *xform)
+get_ecdsa_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function;
@@ -267,7 +267,7 @@ get_ecdsa_function(struct rte_crypto_asym_xform *xform)
}
static struct qat_asym_function
-get_ecpm_function(struct rte_crypto_asym_xform *xform)
+get_ecpm_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function;
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 19931791c4..374452020a 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -129,7 +129,7 @@ cleanup_crt(struct qat_asym_op_cookie *cookie,
static void
cleanup(struct qat_asym_op_cookie *cookie,
- struct rte_crypto_asym_xform *xform, int alg_size)
+ const struct rte_crypto_asym_xform *xform, int alg_size)
{
if (xform->xform_type == RTE_CRYPTO_ASYM_XFORM_MODEX)
cleanup_arrays(cookie, QAT_ASYM_MODEXP_NUM_IN_PARAMS,
@@ -175,7 +175,7 @@ check_zero(rte_crypto_param n)
}
static struct qat_asym_function
-get_asym_function(struct rte_crypto_asym_xform *xform)
+get_asym_function(const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function;
@@ -195,10 +195,10 @@ get_asym_function(struct rte_crypto_asym_xform *xform)
}
static int
-modexp_set_input(struct rte_crypto_asym_op *asym_op,
- struct icp_qat_fw_pke_request *qat_req,
+modexp_set_input(struct icp_qat_fw_pke_request *qat_req,
struct qat_asym_op_cookie *cookie,
- struct rte_crypto_asym_xform *xform)
+ const struct rte_crypto_asym_op *asym_op,
+ const struct rte_crypto_asym_xform *xform)
{
struct qat_asym_function qat_function;
uint32_t alg_bytesize, func_id, in_bytesize;
@@ -245,8 +245,8 @@ modexp_set_input(struct rte_crypto_asym_op *asym_op,
static uint8_t
modexp_collect(struct rte_crypto_asym_op *asym_op,
- struct qat_asym_op_cookie *cookie,
- struct rte_crypto_asym_xform *xform)
+ const struct qat_asym_op_cookie *cookie,
+ const struct rte_crypto_asym_xform *xform)
{
rte_crypto_param n = xform->modex.modulus;
uint32_t alg_bytesize = cookie->alg_bytesize;
@@ -265,10 +265,10 @@ modexp_collect(struct rte_crypto_asym_op *asym_op,
}
static int
-modinv_set_input(struct r
[PATCH 2/3] crypto/qat: add ecdh key exchange algorithm
This commit adds ECDH algorithm to Intel QuickAssist
Technology driver.
Signed-off-by: Arek Kusztal
---
drivers/crypto/qat/qat_asym.c | 94 +++
1 file changed, 94 insertions(+)
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 374452020a..34fb3f5a45 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -760,6 +760,95 @@ ecpm_collect(struct rte_crypto_asym_op *asym_op,
}
static int
+ecdh_set_input(struct icp_qat_fw_pke_request *qat_req,
+ struct qat_asym_op_cookie *cookie,
+ const struct rte_crypto_asym_op *asym_op,
+ const struct rte_crypto_asym_xform *xform)
+{
+ struct qat_asym_function qat_function;
+ uint32_t qat_func_alignsize, func_id;
+ int curve_id;
+
+ curve_id = pick_curve(xform);
+ if (curve_id < 0) {
+ QAT_LOG(DEBUG, "Incorrect elliptic curve");
+ return -EINVAL;
+ }
+
+ qat_function = get_ecpm_function(xform);
+ func_id = qat_function.func_id;
+ if (func_id == 0) {
+ QAT_LOG(ERR, "Cannot obtain functionality id");
+ return -EINVAL;
+ }
+ qat_func_alignsize = RTE_ALIGN_CEIL(qat_function.bytesize, 8);
+
+ if (asym_op->ecdh.ke_type == RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE) {
+ SET_PKE_LN(asym_op->ecdh.priv_key, qat_func_alignsize, 0);
+ SET_PKE_LN_EC(curve[curve_id], x, 1);
+ SET_PKE_LN_EC(curve[curve_id], y, 2);
+ } else {
+ SET_PKE_LN(asym_op->ecdh.priv_key, qat_func_alignsize, 0);
+ SET_PKE_LN(asym_op->ecdh.pub_key.x, qat_func_alignsize, 1);
+ SET_PKE_LN(asym_op->ecdh.pub_key.y, qat_func_alignsize, 2);
+ }
+ SET_PKE_LN_EC(curve[curve_id], a, 3);
+ SET_PKE_LN_EC(curve[curve_id], b, 4);
+ SET_PKE_LN_EC(curve[curve_id], p, 5);
+ SET_PKE_LN_EC(curve[curve_id], h, 6);
+
+ cookie->alg_bytesize = curve[curve_id].bytesize;
+ cookie->qat_func_alignsize = qat_func_alignsize;
+ qat_req->pke_hdr.cd_pars.func_id = func_id;
+ qat_req->input_param_count =
+ QAT_ASYM_ECPM_IN_PARAMS;
+ qat_req->output_param_count =
+ QAT_ASYM_ECPM_OUT_PARAMS;
+
+ HEXDUMP("k", cookie->input_array[0], qat_func_alignsize);
+ HEXDUMP("xG", cookie->input_array[1], qat_func_alignsize);
+ HEXDUMP("yG", cookie->input_array[2], qat_func_alignsize);
+ HEXDUMP("a", cookie->input_array[3], qat_func_alignsize);
+ HEXDUMP("b", cookie->input_array[4], qat_func_alignsize);
+ HEXDUMP("q", cookie->input_array[5], qat_func_alignsize);
+ HEXDUMP("h", cookie->input_array[6], qat_func_alignsize);
+
+ return 0;
+}
+
+static uint8_t
+ecdh_collect(struct rte_crypto_asym_op *asym_op,
+ const struct qat_asym_op_cookie *cookie,
+ const struct rte_crypto_asym_xform *xform)
+{
+ uint8_t *x, *y;
+ uint32_t alg_bytesize = cookie->alg_bytesize;
+ uint32_t qat_func_alignsize = cookie->qat_func_alignsize;
+ uint32_t ltrim = qat_func_alignsize - alg_bytesize;
+
+ if (asym_op->ecdh.ke_type == RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE) {
+ asym_op->ecdh.pub_key.x.length = alg_bytesize;
+ asym_op->ecdh.pub_key.y.length = alg_bytesize;
+ x = asym_op->ecdh.pub_key.x.data;
+ y = asym_op->ecdh.pub_key.y.data;
+ } else {
+ asym_op->ecdh.shared_secret.x.length = alg_bytesize;
+ asym_op->ecdh.shared_secret.y.length = alg_bytesize;
+ x = asym_op->ecdh.shared_secret.x.data;
+ y = asym_op->ecdh.shared_secret.y.data;
+ }
+
+ rte_memcpy(x, &cookie->output_array[0][ltrim], alg_bytesize);
+ rte_memcpy(y, &cookie->output_array[1][ltrim], alg_bytesize);
+
+ HEXDUMP("X", cookie->output_array[0],
+ qat_func_alignsize);
+ HEXDUMP("Y", cookie->output_array[1],
+ qat_func_alignsize);
+ return RTE_CRYPTO_OP_STATUS_SUCCESS;
+}
+
+static int
asym_set_input(struct icp_qat_fw_pke_request *qat_req,
struct qat_asym_op_cookie *cookie,
const struct rte_crypto_asym_op *asym_op,
@@ -781,6 +870,9 @@ asym_set_input(struct icp_qat_fw_pke_request *qat_req,
case RTE_CRYPTO_ASYM_XFORM_ECPM:
return ecpm_set_input(qat_req, cookie,
asym_op, xform);
+ case RTE_CRYPTO_ASYM_XFORM_ECDH:
+ return ecdh_set_input(qat_req, cookie,
+ asym_op, xform);
default:
QAT_LOG(ERR, "Invalid/unsupported asymmetric crypto xform");
return -EINVAL;
@@ -867,6 +959,8 @@ qat_asym_collect_response(struct rte_crypto_op *op,
return ecdsa_collect(asym_op, cookie);
case RTE_CRYPTO_ASYM_XFORM_ECPM:
[PATCH 3/3] crypto/qat: add ecdh public key verification
This commit adds verification option for elliptic curve
points when used along ECDH algorithm.
Signed-off-by: Arek Kusztal
---
drivers/common/qat/qat_adf/qat_pke.h | 24 +++
drivers/crypto/qat/qat_asym.c| 58 +++-
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/drivers/common/qat/qat_adf/qat_pke.h
b/drivers/common/qat/qat_adf/qat_pke.h
index 00e2b776dc..4b09e76dbb 100644
--- a/drivers/common/qat/qat_adf/qat_pke.h
+++ b/drivers/common/qat/qat_adf/qat_pke.h
@@ -290,4 +290,28 @@ get_ecpm_function(const struct rte_crypto_asym_xform
*xform)
return qat_function;
}
+static struct qat_asym_function
+get_ec_verify_function(const struct rte_crypto_asym_xform *xform)
+{
+ struct qat_asym_function qat_function;
+
+ switch (xform->ec.curve_id) {
+ case RTE_CRYPTO_EC_GROUP_SECP256R1:
+ qat_function.func_id = MATHS_POINT_VERIFY_GFP_L256;
+ qat_function.bytesize = 32;
+ break;
+ case RTE_CRYPTO_EC_GROUP_SECP384R1:
+ qat_function.func_id = MATHS_POINT_VERIFY_GFP_L512;
+ qat_function.bytesize = 64;
+ break;
+ case RTE_CRYPTO_EC_GROUP_SECP521R1:
+ qat_function.func_id = MATHS_POINT_VERIFY_GFP_521;
+ qat_function.bytesize = 66;
+ break;
+ default:
+ qat_function.func_id = 0;
+ }
+ return qat_function;
+}
+
#endif
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 34fb3f5a45..33e6ca045f 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -816,6 +816,53 @@ ecdh_set_input(struct icp_qat_fw_pke_request *qat_req,
return 0;
}
+static int
+ecdh_verify_set_input(struct icp_qat_fw_pke_request *qat_req,
+ struct qat_asym_op_cookie *cookie,
+ const struct rte_crypto_asym_op *asym_op,
+ const struct rte_crypto_asym_xform *xform)
+{
+ struct qat_asym_function qat_function;
+ uint32_t qat_func_alignsize, func_id;
+ int curve_id;
+
+ curve_id = pick_curve(xform);
+ if (curve_id < 0) {
+ QAT_LOG(DEBUG, "Incorrect elliptic curve");
+ return -EINVAL;
+ }
+
+ qat_function = get_ec_verify_function(xform);
+ func_id = qat_function.func_id;
+ if (func_id == 0) {
+ QAT_LOG(ERR, "Cannot obtain functionality id");
+ return -EINVAL;
+ }
+ qat_func_alignsize = RTE_ALIGN_CEIL(qat_function.bytesize, 8);
+
+ SET_PKE_LN(asym_op->ecdh.pub_key.x, qat_func_alignsize, 0);
+ SET_PKE_LN(asym_op->ecdh.pub_key.y, qat_func_alignsize, 1);
+ SET_PKE_LN_EC(curve[curve_id], p, 2);
+ SET_PKE_LN_EC(curve[curve_id], a, 3);
+ SET_PKE_LN_EC(curve[curve_id], b, 4);
+
+ cookie->alg_bytesize = curve[curve_id].bytesize;
+ cookie->qat_func_alignsize = qat_func_alignsize;
+ qat_req->pke_hdr.cd_pars.func_id = func_id;
+ qat_req->input_param_count =
+ 5;
+ qat_req->output_param_count =
+ 0;
+
+ HEXDUMP("x", cookie->input_array[0], qat_func_alignsize);
+ HEXDUMP("y", cookie->input_array[1], qat_func_alignsize);
+ HEXDUMP("p", cookie->input_array[2], qat_func_alignsize);
+ HEXDUMP("a", cookie->input_array[3], qat_func_alignsize);
+ HEXDUMP("b", cookie->input_array[4], qat_func_alignsize);
+
+ return 0;
+}
+
static uint8_t
ecdh_collect(struct rte_crypto_asym_op *asym_op,
const struct qat_asym_op_cookie *cookie,
@@ -826,6 +873,9 @@ ecdh_collect(struct rte_crypto_asym_op *asym_op,
uint32_t qat_func_alignsize = cookie->qat_func_alignsize;
uint32_t ltrim = qat_func_alignsize - alg_bytesize;
+ if (asym_op->ecdh.ke_type == RTE_CRYPTO_ASYM_KE_PUB_KEY_VERIFY)
+ return RTE_CRYPTO_OP_STATUS_SUCCESS;
+
if (asym_op->ecdh.ke_type == RTE_CRYPTO_ASYM_KE_PUB_KEY_GENERATE) {
asym_op->ecdh.pub_key.x.length = alg_bytesize;
asym_op->ecdh.pub_key.y.length = alg_bytesize;
@@ -871,8 +921,14 @@ asym_set_input(struct icp_qat_fw_pke_request *qat_req,
return ecpm_set_input(qat_req, cookie,
asym_op, xform);
case RTE_CRYPTO_ASYM_XFORM_ECDH:
- return ecdh_set_input(qat_req, cookie,
+ if (asym_op->ecdh.ke_type ==
+ RTE_CRYPTO_ASYM_KE_PUB_KEY_VERIFY) {
+ return ecdh_verify_set_input(qat_req, cookie,
asym_op, xform);
+ } else {
+ return ecdh_set_input(qat_req, cookie,
+ asym_op, xform);
+ }
default:
QAT_LOG(ERR, "Invalid/unsupported asymmetric crypto xform");
return -EINVAL;
--
2.13.6
RE: [PATCH] net/mlx5: fix matcher priority for esp item
Hi,
> -Original Message-
> From: Bassam Zaid AlKilani
> Sent: Thursday, July 28, 2022 5:12 PM
> To: dev@dpdk.org
> Cc: Raslan Darawsheh ; rzid...@nvidia.com;
> sta...@dpdk.org; Matan Azrad ; Slava Ovsiienko
>
> Subject: [PATCH] net/mlx5: fix matcher priority for esp item
>
> ESP is one of IPSec protocols over both IPv4 and IPv6 and is considered
> a tunnel layer that cannot be followed by any other layer. Taking that
> into consideration, esp is considered as a 4 layer.
>
> Not defining ESP's priority will make it match with the same priority as
> its prior IP layer, which has a layer 3 priority. This will lead to
> issues in matching and will match the packet with the first matching
> rule even if it doesn't have an esp layer in its pattern, disregarding
> any following rules that could have an esp item and can be actually
> a more accurate match since it will have a longer matching criterion.
>
> This is fixed by defining the priority for the ESP item to have a
> layer 4 priority, making the match be for the rule with the more
> accurate and longer matching criteria.
>
> Fixes: 18ca4a4ec73a ("net/mlx5: support ESP SPI match and RSS hash")
> Cc: rzid...@nvidia.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bassam ZaidAlKilani [Raslan Darawsheh]
Acked-by: Raslan Darawsheh
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
[PATCH v2] net/ice: support disabling ACL engine in DCF via devargs
From: Zhichao Zeng
Support disabling DCF ACL engine via devarg "acl=off" in cmdline, aiming to
shorten the DCF startup time.
Signed-off-by: Zhichao Zeng
---
v2: add document for the new devarg
---
doc/guides/nics/ice.rst| 11 ++
drivers/net/ice/ice_dcf_ethdev.c | 58 +++---
drivers/net/ice/ice_dcf_ethdev.h | 6
drivers/net/ice/ice_dcf_parent.c | 3 ++
drivers/net/ice/ice_ethdev.h | 2 ++
drivers/net/ice/ice_generic_flow.c | 12 +++
6 files changed, 79 insertions(+), 13 deletions(-)
diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst
index 6b903b9bbc..3aa58d3f2c 100644
--- a/doc/guides/nics/ice.rst
+++ b/doc/guides/nics/ice.rst
@@ -296,6 +296,17 @@ The DCF PMD needs to advertise and acquire DCF capability
which allows DCF to
send AdminQ commands that it would like to execute over to the PF and receive
responses for the same from PF.
+Additional Options
+++
+
+- ``Disable ACL Engine`` (default ``enabled``)
+
+ By default, all flow engines are enabled. But if user does not need the
+ ACL engine related functions, user can set ``devargs`` parameter
+ ``acl=off`` to disable the ACL engine and shorten the startup time.
+
+-a 18:01.0,cap=dcf,acl=off
+
.. _figure_ice_dcf:
.. figure:: img/ice_dcf.*
diff --git a/drivers/net/ice/ice_dcf_ethdev.c b/drivers/net/ice/ice_dcf_ethdev.c
index 0da267db1f..a51e404e64 100644
--- a/drivers/net/ice/ice_dcf_ethdev.c
+++ b/drivers/net/ice/ice_dcf_ethdev.c
@@ -45,6 +45,26 @@ ice_dcf_dev_init(struct rte_eth_dev *eth_dev);
static int
ice_dcf_dev_uninit(struct rte_eth_dev *eth_dev);
+static int
+ice_dcf_cap_check_handler(__rte_unused const char *key,
+ const char *value, __rte_unused void *opaque);
+
+static int
+ice_dcf_engine_disabled_handler(__rte_unused const char *key,
+ const char *value, __rte_unused void *opaque);
+
+struct ice_devarg {
+ enum ice_dcf_devrarg type;
+ const char *key;
+ int (*handler)(__rte_unused const char *key,
+ const char *value, __rte_unused void *opaque);
+};
+
+static const struct ice_devarg ice_devargs_table[] = {
+ {ICE_DCF_DEVARG_CAP, "cap", ice_dcf_cap_check_handler},
+ {ICE_DCF_DEVARG_ACL, "acl", ice_dcf_engine_disabled_handler},
+};
+
struct rte_ice_dcf_xstats_name_off {
char name[RTE_ETH_XSTATS_NAME_SIZE];
unsigned int offset;
@@ -1909,6 +1929,16 @@ ice_dcf_dev_uninit(struct rte_eth_dev *eth_dev)
return 0;
}
+static int
+ice_dcf_engine_disabled_handler(__rte_unused const char *key,
+ const char *value, __rte_unused void *opaque)
+{
+ if (strcmp(value, "off"))
+ return -1;
+
+ return 0;
+}
+
static int
ice_dcf_cap_check_handler(__rte_unused const char *key,
const char *value, __rte_unused void *opaque)
@@ -1919,11 +1949,11 @@ ice_dcf_cap_check_handler(__rte_unused const char *key,
return 0;
}
-static int
-ice_dcf_cap_selected(struct rte_devargs *devargs)
+int
+ice_devargs_check(struct rte_devargs *devargs, enum ice_dcf_devrarg
devarg_type)
{
struct rte_kvargs *kvlist;
- const char *key = "cap";
+ unsigned int i = 0;
int ret = 0;
if (devargs == NULL)
@@ -1933,16 +1963,18 @@ ice_dcf_cap_selected(struct rte_devargs *devargs)
if (kvlist == NULL)
return 0;
- if (!rte_kvargs_count(kvlist, key))
- goto exit;
-
- /* dcf capability selected when there's a key-value pair: cap=dcf */
- if (rte_kvargs_process(kvlist, key,
- ice_dcf_cap_check_handler, NULL) < 0)
- goto exit;
-
- ret = 1;
+ for (i = 0; i < ARRAY_SIZE(ice_devargs_table); i++) {
+ if (devarg_type == ice_devargs_table[i].type) {
+ if (!rte_kvargs_count(kvlist, ice_devargs_table[i].key))
+ goto exit;
+ if (rte_kvargs_process(kvlist, ice_devargs_table[i].key,
+ ice_devargs_table[i].handler, NULL) < 0)
+ goto exit;
+ ret = 1;
+ break;
+ }
+ }
exit:
rte_kvargs_free(kvlist);
return ret;
@@ -1960,7 +1992,7 @@ eth_ice_dcf_pci_probe(__rte_unused struct rte_pci_driver
*pci_drv,
uint16_t dcf_vsi_id;
int i, ret;
- if (!ice_dcf_cap_selected(pci_dev->device.devargs))
+ if (!ice_devargs_check(pci_dev->device.devargs, ICE_DCF_DEVARG_CAP))
return 1;
ret = rte_eth_devargs_parse(pci_dev->device.devargs->args, ð_da);
diff --git a/drivers/net/ice/ice_dcf_ethdev.h b/drivers/net/ice/ice_dcf_ethdev.h
index 27f6402786..4baaec4b8b 100644
--- a/drivers/net/ice/ice_dcf_ethdev.h
+++ b/drivers/net/ice/ice_dcf_ethdev.h
@@ -64,12 +64,18 @@ struct ice_dc
RE: [PATCH] net/mlx5: fix check for orphan wait descriptor
Hi,
> -Original Message-
> From: Slava Ovsiienko
> Sent: Thursday, August 11, 2022 8:51 AM
> To: dev@dpdk.org
> Cc: ferruh.yi...@intel.com; Matan Azrad ; Raslan
> Darawsheh ; sta...@dpdk.org
> Subject: [PATCH] net/mlx5: fix check for orphan wait descriptor
>
> The mlx5 PMD supports send scheduling feature, it allows
> to send packets at specified moment of time, to do that
> PMD pushes special wait descriptor (WQE) to the hardware
> queue and then pushes descriptor for packet data as usual.
> If queue is close to be full or there is no enough elts
> buffers to store mbufs being sent the data descriptors might
> be not pushed and the orphan wait WQE (not followed by the
> data) might reside in queue on tx_burst routine exit.
>
> To avoid orphan wait WQEs there was the check for enough
> free space in the queue WQE buffer and enough amount of the
> free elts in queue mbuf storage. This check was incomplete
> and did not cover all the cases for Enhanced Multi-Packet
> Write descriptors.
>
> Fixes: 2f827f5ea6e1 ("net/mlx5: support scheduling on send routine
> template")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
RE: [PATCH v2] net/mlx5: fix single not inline packet elts storing
Hi,
> -Original Message-
> From: Slava Ovsiienko
> Sent: Wednesday, August 17, 2022 10:04 AM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; sta...@dpdk.org
> Subject: [PATCH v2] net/mlx5: fix single not inline packet elts storing
>
> The mlx5 PMD can inline packet data into transmitting descriptor (WQE)
> and free mbuf immediately as data no longer needed, for non-inline
> packets the mbuf pointer should be stored in elts array for coming
> freeing on send completion. There was an optimization on storing
> pointers in batch and there was missed storing mbuf for single
> packet if non-inline was explicitly requested by flag.
>
> Fixes: cacb44a09962 ("net/mlx5: add no-inline Tx flag")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Viacheslav Ovsiienko
> ---
> v2: "Fixes tag" added
>
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
[Bug 1066] [dpdk20.11.6-rc1] dpdk20.11.6-rc1 compiled failed with kmods enable
https://bugs.dpdk.org/show_bug.cgi?id=1066 liweiyuan (weiyuanx...@intel.com) changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from liweiyuan (weiyuanx...@intel.com) --- Patch has been merged to dpdk20.11 close this bug. -- You are receiving this mail because: You are the assignee for the bug.
[PATCH] common/qat: read slice configuration
Read slice configuration of QAT capabilities.
Signed-off-by: Arek Kusztal
---
drivers/common/qat/qat_device.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/common/qat/qat_device.c b/drivers/common/qat/qat_device.c
index db4b087d2b..d25a696c5e 100644
--- a/drivers/common/qat/qat_device.c
+++ b/drivers/common/qat/qat_device.c
@@ -368,6 +368,7 @@ static int qat_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
{ SYM_ENQ_THRESHOLD_NAME, 0 },
{ ASYM_ENQ_THRESHOLD_NAME, 0 },
{ COMP_ENQ_THRESHOLD_NAME, 0 },
+ { "DISABLE SLICE", 0},
{ NULL, 0 },
};
@@ -390,6 +391,17 @@ static int qat_pci_probe(struct rte_pci_driver *pci_drv
__rte_unused,
return -ENODEV;
}
+ if (qat_pci_dev->qat_dev_gen == QAT_GEN3) {
+ uint32_t capa = 0;
+ const uint32_t offset = 0x4c;
+
+ if (rte_pci_read_config(pci_dev, &capa, 4, offset) < 0) {
+ RTE_LOG(ERR, EAL,
+ "Cannot read slice configuration\n");
+ }
+ qat_dev_cmd_param[4].val |= (0x400 & capa) | (0x800 & capa);
+ }
+
sym_ret = qat_sym_dev_create(qat_pci_dev, qat_dev_cmd_param);
if (sym_ret == 0) {
num_pmds_created++;
--
2.17.1
RE: 21.11.2 patches review and test
> -Original Message- > From: Luca Boccassi > Sent: Tuesday, August 16, 2022 7:40 PM > To: Jiang, YuX ; sta...@dpdk.org > Cc: dev@dpdk.org; Walker, Benjamin > Subject: Re: 21.11.2 patches review and test > > On Thu, 2022-08-04 at 07:28 +, Jiang, YuX wrote: > > > -Original Message- > > > From: Jiang, YuX > > > Sent: Tuesday, August 2, 2022 6:15 PM > > > To: Luca Boccassi ; sta...@dpdk.org > > > Cc: dev@dpdk.org; Walker, Benjamin ; > > > Raslan Darawsheh ; Thomas Monjalon > > > ; yangh...@redhat.com > > > Subject: RE: 21.11.2 patches review and test > > > > > > > -Original Message- > > > > From: Luca Boccassi > > > > Sent: Tuesday, August 2, 2022 6:01 PM > > > > To: Jiang, YuX ; sta...@dpdk.org > > > > Cc: dev@dpdk.org; Walker, Benjamin ; > > > Raslan > > > > Darawsheh ; Thomas Monjalon > > > ; > > > > yangh...@redhat.com > > > > Subject: Re: 21.11.2 patches review and test > > > > > > > > On Fri, 2022-07-29 at 11:26 +, Jiang, YuX wrote: > > > > > > -Original Message- > > > > > > From: Jiang, YuX > > > > > > Sent: Friday, July 29, 2022 11:01 AM > > > > > > To: Luca Boccassi ; sta...@dpdk.org > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > > > > ; Ali Alnubani > > > > > > ; Walker, Benjamin > > > > > > ; David Christensen > > > > > > ; Hemant Agrawal > > > > ; > > > > > > Stokes, Ian ; Jerin Jacob > > > > > > ; Mcnamara, John > > > > > > ; Ju-Hyoung Lee > > > > > > ; Kevin Traynor ; > > > > > > Pei Zhang ; Xu, Qian > > > Q > > > > > > ; Raslan Darawsheh ; > > > > Thomas > > > > > > Monjalon ; Peng, Yuan > > > > ; > > > > > > Chen, Zhaoyan ; yangh...@redhat.com > > > > > > Subject: RE: 21.11.2 patches review and test > > > > > > > > > > > > > -Original Message- > > > > > > > From: Luca Boccassi > > > > > > > Sent: Thursday, July 28, 2022 8:34 PM > > > > > > > To: sta...@dpdk.org > > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > > > > ; > > > > > > > Ali Alnubani ; Walker, Benjamin > > > > > > > ; David Christensen > > > > > > > ; Hemant Agrawal > > > > ; > > > > > > > Stokes, Ian ; Jerin Jacob < > > > > > > > jer...@marvell.com>; Mcnamara, John > > > > > > > ; Ju-Hyoung Lee > > > > > > > ; Kevin Traynor ; > > > > > > > Pei > > > > > > Zhang > > > > > > > ; Xu, Qian Q ; > > > > > > > Raslan Darawsheh ; Thomas Monjalon > > > > > > ; > > > > > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > > ; yangh...@redhat.com > > > > > > > Subject: Re: 21.11.2 patches review and test > > > > > > > > > > > > > > On Mon, 2022-07-18 at 10:58 +0100, luca.bocca...@gmail.com > > > > > > > wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > Here is a list of patches targeted for stable release > > > > > > > > 21.11.2. > > > > > > > > > > > > > > > > The planned date for the final release is August 29th. > > > > > > > > > > > > > > > > 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=v21.11.2-rc1 > > > > > > > > > > > > > > > > These patches are located at branch 21.11 of dpdk-stable > > > > > > > > repo: > > > > > > > > https://dpdk.org/browse/dpdk-stable/ > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Luca Boccassi > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > Any update from any of the validation teams? Any indication > > > > > > > on how the tests are going? > > > > > > > > > > > > > > -- > > > > > > > Kind regards, > > > > > > > Luca Boccassi > > > > > > > > > > > > Everything is fine, find one vhost related issue which is > > > > > > investigated by Intel Dev. > > > > > > I will send a v1 report later. Thanks. > > > > > > > > > > > > Best regards, > > > > > > Yu Jiang > > > > > > > > > > Update the test status for Intel part. Till now dpdk21.11.2-rc1 > > > > > test rate is 90%, no critical issue is found. > > > > > Failure defects as below: > > > > > Bug1: [dpdk v21.11.2-rc1] examples/performance-thread meson > > > > > build error with gcc12.1 on fedora36 > > > > > Bug2: DPDK 21.11.1 cryptodev_qat_raw_api_autotest failing > > > > > - Intel Dev send a patch to skip oop test for raw api, > > > > > need be reviewed and merged. > > > > > > > > Hi, > > > > > > > > Do you have a reference to this patch? I did not see anything new > > > > sent to stable in the past week or so > > > > > > > > > > Yes, he only send an attached file, I will check this with Intel > > > Dev. Thanks. > > > > > > > > Bug3: [21.11LTS]Test with the new local patch, Vhost-user > > > > > meet > > > > > Segmentation fault issue when quit virtio-user before stopping > > > > > sending packets > > > > > - Intel Dev is under in
RE: [EXT] [PATCH 2/4] cryptodev: add SM3 hash algorithm
Hi Arek,
Please see inline.
Thanks,
Anoob
>
> External Email
>
> --
> SM3 is a cryptographic hash function used in the Chinese National Standard.
>
> - Added SM3 algorithm
>
> Signed-off-by: Arek Kusztal
> ---
[snip]
> a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c index
> 266804f0fe..2b6c7de930 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -135,7 +135,8 @@ rte_crypto_auth_algorithm_strings[] = {
>
> [RTE_CRYPTO_AUTH_KASUMI_F9] = "kasumi-f9",
> [RTE_CRYPTO_AUTH_SNOW3G_UIA2] = "snow3g-uia2",
> - [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3"
> + [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3",
> + [RTE_CRYPTO_AUTH_SM3] = "zuc-sm3"
[Anoob] Should the string be "sm3" instead of "zuc-sm3"?
[PATCH] app/test: random test vectors for Asymc RSA
This patch add random test vectors generator for asymc RSA algorithm,
base on OpenSSL 1.1.x lib.
Added functions for create RSA test vectors base on defined rules.
The randome generated test vector include plaintext, RSA key in exponent
and quintuple format, digest and expected cipher and sign.
Replace crypto_testsuite_params_asym struct from test_cryptodev_asym.c
to test_cryptodev_asym_types.h, as it's used in other test suit.
Description of new files:
test_cryptodev_asym_creator.c: generator for random plaintext
test_cryptodev_asym_rsa_creator.c: RSA vector generator
test_cryptodev_asym_rsa_creator.c RSA test suite
test_cryptodev_asym_vectors.c: memory allocator for vectors
Signed-off-by: Przemyslaw Zegan
---
app/test/meson.build | 5 +
app/test/test_cryptodev_asym.c | 63 ++--
app/test/test_cryptodev_asym_common.c| 117 +++
app/test/test_cryptodev_asym_common.h| 49 +++
app/test/test_cryptodev_asym_creator.c | 41 +++
app/test/test_cryptodev_asym_creator.h | 13 +
app/test/test_cryptodev_asym_rsa.c | 308 +++
app/test/test_cryptodev_asym_rsa.h | 17 +
app/test/test_cryptodev_asym_rsa_creator.c | 144 +
app/test/test_cryptodev_asym_rsa_creator.h | 15 +
app/test/test_cryptodev_asym_types.h | 20 ++
app/test/test_cryptodev_asym_vectors.c | 29 ++
app/test/test_cryptodev_asym_vectors.h | 18 ++
app/test/test_cryptodev_asym_vectors_def.h | 135
app/test/test_cryptodev_asym_vectors_rules.h | 43 +++
lib/cryptodev/rte_crypto_asym.h | 1 +
16 files changed, 984 insertions(+), 34 deletions(-)
create mode 100644 app/test/test_cryptodev_asym_common.c
create mode 100644 app/test/test_cryptodev_asym_common.h
create mode 100644 app/test/test_cryptodev_asym_creator.c
create mode 100644 app/test/test_cryptodev_asym_creator.h
create mode 100644 app/test/test_cryptodev_asym_rsa.c
create mode 100644 app/test/test_cryptodev_asym_rsa.h
create mode 100644 app/test/test_cryptodev_asym_rsa_creator.c
create mode 100644 app/test/test_cryptodev_asym_rsa_creator.h
create mode 100644 app/test/test_cryptodev_asym_types.h
create mode 100644 app/test/test_cryptodev_asym_vectors.c
create mode 100644 app/test/test_cryptodev_asym_vectors.h
create mode 100644 app/test/test_cryptodev_asym_vectors_def.h
create mode 100644 app/test/test_cryptodev_asym_vectors_rules.h
diff --git a/app/test/meson.build b/app/test/meson.build
index 431c5bd318..8dc5a3e516 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -146,6 +146,11 @@ test_sources = files(
'test_trace_perf.c',
'test_version.c',
'virtual_pmd.c',
+'test_cryptodev_asym_common.c',
+'test_cryptodev_asym_vectors.c',
+'test_cryptodev_asym_rsa.c',
+'test_cryptodev_asym_rsa_creator.c',
+'test_cryptodev_asym_creator.c'
)
test_deps = enabled_libs
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index fc1a727472..b692af3760 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -23,6 +23,8 @@
#include "test_cryptodev_rsa_test_vectors.h"
#include "test_cryptodev_asym_util.h"
#include "test.h"
+#include "test_cryptodev_asym_types.h"
+#include "test_cryptodev_asym_rsa.h"
#define TEST_NUM_BUFS 10
#define TEST_NUM_SESSIONS 4
@@ -34,14 +36,6 @@
#define TEST_VECTOR_SIZE 256
static int gbl_driver_id;
-struct crypto_testsuite_params_asym {
- struct rte_mempool *op_mpool;
- struct rte_mempool *session_mpool;
- struct rte_cryptodev_config conf;
- struct rte_cryptodev_qp_conf qp_conf;
- uint8_t valid_devs[RTE_CRYPTO_MAX_DEVS];
- uint8_t valid_dev_count;
-};
struct crypto_unittest_params {
void *sess;
@@ -62,12 +56,12 @@ static struct test_cases_array test_vector = {0, { NULL } };
static uint32_t test_index;
-static struct crypto_testsuite_params_asym testsuite_params = { NULL };
+struct crypto_testsuite_params_asym testsuite_params_asym = { NULL };
static int
queue_ops_rsa_sign_verify(void *sess)
{
- struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
+ struct crypto_testsuite_params_asym *ts_params = &testsuite_params_asym;
struct rte_mempool *op_mpool = ts_params->op_mpool;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *op, *result_op;
@@ -158,7 +152,7 @@ queue_ops_rsa_sign_verify(void *sess)
static int
queue_ops_rsa_enc_dec(void *sess)
{
- struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
+ struct crypto_testsuite_params_asym *ts_params = &testsuite_params_asym;
struct rte_mempool *op_mpool = ts_params->op_mpool;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *op, *result_op;
@@ -524,7 +518,7 @@ test_one_case(const void *test_case, int sessionless)
if (tc.modex.
[PATCH] net/mlx5: fix the inline length exceeding descriptor limit
The hardware descriptor (WQE) length field is 6 bits wide
and we have the native limitation for the overall descriptor
length. To improve the PCIe bandwidth the packet data can be
inline into descriptor. If PMD was configured to inline large
amount of data it happened there was no enough space remaining
in the descriptor to specify all the packet data segments and
PMD rejected problematic packets.
The patch tries to adjust the inline data length conservatively
and allows to avoid error occurring.
Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
Fixes: e2259f93ef45 ("net/mlx5: fix Tx when inlining is impossible")
Cc: sta...@dpdk.org
Signed-off-by: Viacheslav Ovsiienko
Reviewed-by: Dmitry Kozlyuk
---
drivers/net/mlx5/mlx5_tx.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_tx.h b/drivers/net/mlx5/mlx5_tx.h
index 8e113e3778..59ebe95032 100644
--- a/drivers/net/mlx5/mlx5_tx.h
+++ b/drivers/net/mlx5/mlx5_tx.h
@@ -2078,8 +2078,24 @@ mlx5_tx_packet_multi_inline(struct mlx5_txq_data
*__rte_restrict txq,
if (unlikely(loc->wqe_free < ((ds + 3) / 4)))
return MLX5_TXCMP_CODE_EXIT;
/* Check for maximal WQE size. */
- if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ds))
- return MLX5_TXCMP_CODE_ERROR;
+ if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ds)) {
+ /* Check if we can adjust the inline length. */
+ if (unlikely(txq->inlen_mode)) {
+ ds = NB_SEGS(loc->mbuf) + 2 +
+ (txq->inlen_mode -
+ MLX5_ESEG_MIN_INLINE_SIZE +
+ MLX5_WSEG_SIZE +
+ MLX5_WSEG_SIZE - 1) / MLX5_WSEG_SIZE;
+ if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ds))
+ return MLX5_TXCMP_CODE_ERROR;
+ }
+ /* We have lucky opportunity to adjust. */
+ inlen = RTE_MIN(inlen, MLX5_WQE_SIZE_MAX -
+ MLX5_WSEG_SIZE * 2 -
+ MLX5_WSEG_SIZE * NB_SEGS(loc->mbuf) -
+ MLX5_WSEG_SIZE +
+ MLX5_ESEG_MIN_INLINE_SIZE);
+ }
#ifdef MLX5_PMD_SOFT_COUNTERS
/* Update sent data bytes/packets counters. */
txq->stats.obytes += dlen + vlan;
--
2.18.1
[dpdk-dev v2] app/test: random test vectors for Asymc RSA
This patch add random test vectors generator for asymc RSA algorithm,
base on OpenSSL 1.1.x lib.
Added functions for create RSA test vectors base on defined rules.
The randome generated test vector include plaintext, RSA key in exponent
and quintuple format, digest and expected cipher and sign.
Replace crypto_testsuite_params_asym struct from test_cryptodev_asym.c
to test_cryptodev_asym_types.h, as it's used in other test suit.
Description of new files:
test_cryptodev_asym_creator.c: generator for random plaintext
test_cryptodev_asym_rsa_creator.c: RSA vector generator
test_cryptodev_asym_rsa_creator.c RSA test suite
test_cryptodev_asym_vectors.c: memory allocator for vectors
Signed-off-by: Przemyslaw Zegan
---
v2: fixed coding style issues
---
app/test/meson.build | 5 +
app/test/test_cryptodev_asym.c | 63 ++--
app/test/test_cryptodev_asym_common.c| 117 +++
app/test/test_cryptodev_asym_common.h| 49 +++
app/test/test_cryptodev_asym_creator.c | 42 +++
app/test/test_cryptodev_asym_creator.h | 13 +
app/test/test_cryptodev_asym_rsa.c | 309 +++
app/test/test_cryptodev_asym_rsa.h | 17 +
app/test/test_cryptodev_asym_rsa_creator.c | 145 +
app/test/test_cryptodev_asym_rsa_creator.h | 16 +
app/test/test_cryptodev_asym_types.h | 20 ++
app/test/test_cryptodev_asym_vectors.c | 31 ++
app/test/test_cryptodev_asym_vectors.h | 18 ++
app/test/test_cryptodev_asym_vectors_def.h | 132
app/test/test_cryptodev_asym_vectors_rules.h | 42 +++
lib/cryptodev/rte_crypto_asym.h | 1 +
16 files changed, 986 insertions(+), 34 deletions(-)
create mode 100644 app/test/test_cryptodev_asym_common.c
create mode 100644 app/test/test_cryptodev_asym_common.h
create mode 100644 app/test/test_cryptodev_asym_creator.c
create mode 100644 app/test/test_cryptodev_asym_creator.h
create mode 100644 app/test/test_cryptodev_asym_rsa.c
create mode 100644 app/test/test_cryptodev_asym_rsa.h
create mode 100644 app/test/test_cryptodev_asym_rsa_creator.c
create mode 100644 app/test/test_cryptodev_asym_rsa_creator.h
create mode 100644 app/test/test_cryptodev_asym_types.h
create mode 100644 app/test/test_cryptodev_asym_vectors.c
create mode 100644 app/test/test_cryptodev_asym_vectors.h
create mode 100644 app/test/test_cryptodev_asym_vectors_def.h
create mode 100644 app/test/test_cryptodev_asym_vectors_rules.h
diff --git a/app/test/meson.build b/app/test/meson.build
index 431c5bd318..8dc5a3e516 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -146,6 +146,11 @@ test_sources = files(
'test_trace_perf.c',
'test_version.c',
'virtual_pmd.c',
+'test_cryptodev_asym_common.c',
+'test_cryptodev_asym_vectors.c',
+'test_cryptodev_asym_rsa.c',
+'test_cryptodev_asym_rsa_creator.c',
+'test_cryptodev_asym_creator.c'
)
test_deps = enabled_libs
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index fc1a727472..b692af3760 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -23,6 +23,8 @@
#include "test_cryptodev_rsa_test_vectors.h"
#include "test_cryptodev_asym_util.h"
#include "test.h"
+#include "test_cryptodev_asym_types.h"
+#include "test_cryptodev_asym_rsa.h"
#define TEST_NUM_BUFS 10
#define TEST_NUM_SESSIONS 4
@@ -34,14 +36,6 @@
#define TEST_VECTOR_SIZE 256
static int gbl_driver_id;
-struct crypto_testsuite_params_asym {
- struct rte_mempool *op_mpool;
- struct rte_mempool *session_mpool;
- struct rte_cryptodev_config conf;
- struct rte_cryptodev_qp_conf qp_conf;
- uint8_t valid_devs[RTE_CRYPTO_MAX_DEVS];
- uint8_t valid_dev_count;
-};
struct crypto_unittest_params {
void *sess;
@@ -62,12 +56,12 @@ static struct test_cases_array test_vector = {0, { NULL } };
static uint32_t test_index;
-static struct crypto_testsuite_params_asym testsuite_params = { NULL };
+struct crypto_testsuite_params_asym testsuite_params_asym = { NULL };
static int
queue_ops_rsa_sign_verify(void *sess)
{
- struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
+ struct crypto_testsuite_params_asym *ts_params = &testsuite_params_asym;
struct rte_mempool *op_mpool = ts_params->op_mpool;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *op, *result_op;
@@ -158,7 +152,7 @@ queue_ops_rsa_sign_verify(void *sess)
static int
queue_ops_rsa_enc_dec(void *sess)
{
- struct crypto_testsuite_params_asym *ts_params = &testsuite_params;
+ struct crypto_testsuite_params_asym *ts_params = &testsuite_params_asym;
struct rte_mempool *op_mpool = ts_params->op_mpool;
uint8_t dev_id = ts_params->valid_devs[0];
struct rte_crypto_op *op, *result_op;
@@ -524,7 +518,7 @@ test_one_case(const void *test_case, int se
[PATCH] net/mlx5: fix condition to avoid Tx failure
From: Raja Zidane
If hardware descriptor (WQE) length exceeds one the HW can handle,
the Tx queue failure occurs. PMD does the length check but there was
a bug - the length limit was expressed in 16B units (WQEBB segments),
while the calculated WQE length and limit were in 64B units (WQEBBs).
Fix the condition to avoid subsequent Tx queue failure.
Fixes: 18a1c20 ("net/mlx5: implement Tx burst template")
Cc: sta...@dpdk.org
Signed-off-by: Raja Zidane
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_tx.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_tx.h b/drivers/net/mlx5/mlx5_tx.h
index 59ebe95032..e0fc1872fe 100644
--- a/drivers/net/mlx5/mlx5_tx.h
+++ b/drivers/net/mlx5/mlx5_tx.h
@@ -1783,7 +1783,7 @@ mlx5_tx_packet_multi_tso(struct mlx5_txq_data
*__rte_restrict txq,
if (unlikely(loc->wqe_free < ((ds + 3) / 4)))
return MLX5_TXCMP_CODE_EXIT;
/* Check for maximal WQE size. */
- if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ((ds + 3) / 4)))
+ if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ds))
return MLX5_TXCMP_CODE_ERROR;
#ifdef MLX5_PMD_SOFT_COUNTERS
/* Update sent data bytes/packets counters. */
@@ -1858,7 +1858,7 @@ mlx5_tx_packet_multi_send(struct mlx5_txq_data
*__rte_restrict txq,
if (unlikely(loc->wqe_free < ((ds + 3) / 4)))
return MLX5_TXCMP_CODE_EXIT;
/* Check for maximal WQE size. */
- if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ((ds + 3) / 4)))
+ if (unlikely((MLX5_WQE_SIZE_MAX / MLX5_WSEG_SIZE) < ds))
return MLX5_TXCMP_CODE_ERROR;
/*
* Some Tx offloads may cause an error if packet is not long enough,
--
2.18.1
Re: [dpdk-dev] [RFC PATCH 0/1] mldev: introduce machine learning device library
On Tue, Aug 16, 2022 at 10:04 PM Honnappa Nagarahalli wrote: > > > > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com] > > > Sent: Tuesday, 16 August 2022 15.13 > > > > > > On Wed, Aug 3, 2022 at 8:49 PM Stephen Hemminger > > > wrote: > > > > > > > > On Wed, 3 Aug 2022 18:58:37 +0530 > > > > wrote: > > > > > > > > > Roadmap > > > > > --- > > > > > 1) Address the comments for this RFC. > > > > > 2) Common code for mldev > > > > > 3) SW mldev driver based on TVM (https://tvm.apache.org/) > > > > > > > > Having a SW implementation is important because then it can be > > > covered > > > > by tests. > > > > > > Yes. That reason for adding TVM based SW driver as item (3). > > > > > > Is there any other high level or API level comments before proceeding > > > with v1 and implementation. > > > > Have you seriously considered if the DPDK Project is the best home for this > > project? I can easily imagine the DPDK development process being a hindrance > > in many aspects for an evolving AI/ML library. Off the top of my head, it > > would > > probably be better off as a separate project, like SPDK. > There is a lot of talk about using ML in networking workloads. Although, I am > not very sure on how the use case looks like. For ex: is the inference engine > going to be inline (i.e. the packet goes through the inference engine before > coming to the CPU and provide some data (what sort of data?)), look aside > (does it require the packets to be sent to the inference engine or is it some > other data?), what would be an end to end use case? A sample application > using these APIs would be helpful. Simple application for the inference usage is added in the cover letter. Regarding the use cases, There are many like firewall, intrusion detection etc. Most of the use cases are driven by product requirements and SW IP vendors try to keep it to themselves as a product differentiate factor. That is the prime reason for DPDK scope only for inference where IO is involved. Model creation and training etc will heavily vary based on use case but not the inference model. > > IMO, if we need to share the packets with the inference engine, then it fits > into DPDK. Yes. Yes for networking or ORAN use cases the interface data comes over wire and result can go over wire. > > As I understand, there are many mature open source projects for ML/inference > outside of DPDK. Does it make sense for DPDK to adopt those projects rather > than inventing our own? # AI/ML compiler libraries more focused on model creation and training etc (Thats where actual value addition the AI/ML libraries can offer) and minimal part for inference (It is just added for testing the model) # Considering the inference is the scope of the DPDK. DPDK is ideal place for following reasons a) Inference scope is very limited. b) Avoid memcpy of inference data (Use directly from network or other class of device like cryptodev, regexdev) c) Reuse highspeed IO interface like PCI backed driver etc d) Integration with other DPDK subsystems like eventdev etc for job completion. e) Also support more inline offloads by merging two device classes like rte_secuity. f) Run the inference model from different AI/ML compiler frameworks or abstract the inference usage. Similar concept is already applied to other DPDK device classes like 1) In Regexdev, The compiler generates the rule database which is out of scope of DPDK. DPDK API just loads the rule database 2) In Gpudev, The GPU kernel etc out of scope of DPDK.DPDK cares about IO interface. > > > > > If all this stuff can be completely omitted at build time, I have no > > objections. > > > > A small note about naming (not intending to start a flame war, so please > > feel > > free to ignore!): I haven't worked seriously with ML/AI since university > > three > > decades ago, so I'm quite rusty in the domain. However, I don't see any > > Machine Learning functions proposed by this API. The library provides an > > API to > > an Inference Engine - but nobody says the inference model stems from > > Machine Learning; it might as well be a hand crafted model. Do you plan to > > propose APIs for training the models? If not, the name of the library could > > confuse some potential users. > I think, at least on the edge devices, we need an inference device as ML > requires more cycles/power. > > > > > > Or Anyone else interested to review or contribute to this new DPDK > > > device class? >
Re: [RFC] Dynamic log/trace control via telemetry
2022-08-16 19:08 (UTC-0700), Stephen Hemminger: > Not sure if turning telemetry into a do all control api makes sense. I'm sure it doesn't, for "do all". Controlling diagnostic collection and output, however, is directly related to the telemetry purpose. > This seems like a different API. > Also, the default would have to be disabled for application safety reasons. This feature would be for collecting additional info in case the collection was not planned and a restart is not desired. If it is disabled by default, it is likely to be off when it's needed. Let's consider how exactly can safety be compromised. 1. Securing telemetry socket access is out of scope for DPDK, that is, any successful access is considered trusted. 2. Even read-only telemetry still comes at cost, for example, memory telemetry takes a global lock that blocks all allocations, so affecting the app performance is already possible. 3. Important logs and traces enabled at startup may be disabled dynamically. If it's an issue, the API can refuse to disable them. 4. Bogus logs may flood the output and slow down the app. Bogus traces can exhaust disk space. Logs should be monitored automatically, so flooding is just an annoyance. Disk space can have a quota. Since the user is trusted (item 1), even if they do it by mistake, they can quickly correct themselves using the same API.
Re: [RFC] Dynamic log/trace control via telemetry
On Wed, 17 Aug 2022 18:15:03 +0300 Dmitry Kozlyuk wrote: > 2022-08-16 19:08 (UTC-0700), Stephen Hemminger: > > Not sure if turning telemetry into a do all control api makes sense. > > I'm sure it doesn't, for "do all". > Controlling diagnostic collection and output, however, > is directly related to the telemetry purpose. > > > This seems like a different API. > > Also, the default would have to be disabled for application safety reasons. > > > > This feature would be for collecting additional info > in case the collection was not planned and a restart is not desired. > If it is disabled by default, it is likely to be off when it's needed. > > Let's consider how exactly can safety be compromised. > > 1. Securing telemetry socket access is out of scope for DPDK, >that is, any successful access is considered trusted. > > 2. Even read-only telemetry still comes at cost, for example, >memory telemetry takes a global lock that blocks all allocations, >so affecting the app performance is already possible. > > 3. Important logs and traces enabled at startup may be disabled dynamically. >If it's an issue, the API can refuse to disable them. > > 4. Bogus logs may flood the output and slow down the app. >Bogus traces can exhaust disk space. >Logs should be monitored automatically, so flooding is just an annoyance. >Disk space can have a quota. >Since the user is trusted (item 1), even if they do it by mistake, >they can quickly correct themselves using the same API. There can be security impact to telemetry. There always is some performance cost to telemetry. My interest is that we run a performance sensitive application and it gets lots of security review. If a new version of DPDK magically enabled something that had impact, you would cause extra effort and confusion. Developers often have the wrong point of view "my feature is great, everyone wants it" and also "why should I test with this disabled". New features should be opt-in not opt-out.
RE: [RFC] Dynamic log/trace control via telemetry
> From: Dmitry Kozlyuk [mailto:dmitry.kozl...@gmail.com] > Sent: Wednesday, 17 August 2022 17.15 > > 2022-08-16 19:08 (UTC-0700), Stephen Hemminger: > > Not sure if turning telemetry into a do all control api makes sense. > > I'm sure it doesn't, for "do all". > Controlling diagnostic collection and output, however, > is directly related to the telemetry purpose. > > > This seems like a different API. I agree with Stephen regarding not making the telemetry library a "do all" control API. A separate API would be preferable. And then, a wrapper through the telemetry interface can be provided to that API. Best of both worlds. :-) > > Also, the default would have to be disabled for application safety > reasons. > > This feature would be for collecting additional info > in case the collection was not planned and a restart is not desired. > If it is disabled by default, it is likely to be off when it's needed. All tracing, logging etc. MUST be disabled by default. You are suggesting the opposite, which will definitely impact performance. And performance will become a valid argument for not adding more trace/logging to libraries, if all of it is enabled by default. And my usual rant: I hope all of this can be disabled at build time - for maximum performance. > > Let's consider how exactly can safety be compromised. > > 1. Securing telemetry socket access is out of scope for DPDK, >that is, any successful access is considered trusted. > > 2. Even read-only telemetry still comes at cost, for example, >memory telemetry takes a global lock that blocks all allocations, >so affecting the app performance is already possible. > > 3. Important logs and traces enabled at startup may be disabled > dynamically. >If it's an issue, the API can refuse to disable them. > > 4. Bogus logs may flood the output and slow down the app. >Bogus traces can exhaust disk space. >Logs should be monitored automatically, so flooding is just an > annoyance. >Disk space can have a quota. >Since the user is trusted (item 1), even if they do it by mistake, >they can quickly correct themselves using the same API. > Here's a thought: Add an API to set an "unlock key", so applications who don't want to allow these features for unauthorized users can prevent them from enabling it. Authorized users can use an API to unlock these features by providing the key.
[PATCH v2 1/5] mbuf: clarify meta data needed for Outbound Inline
Clarify mbuf meta data needed for Outbound Inline processing.
Application needs to provide mbuf.l3_len and L3 type in
mbuf.ol_flags so that like tunnel mode using mbuf.l2_len, transport mode
can make use of l3_len and l3_type to determine perform
proper transport mode IPsec processing.
Signed-off-by: Nithin Dabilpuram
---
v2:
- Modified ipsec-secgw to do ether type update for outbound path.
doc/guides/nics/features.rst | 2 +-
lib/mbuf/rte_mbuf_core.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 7f6cb91..b4a8e98 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -431,7 +431,7 @@ protocol operations. See security library and PMD
documentation for more details
* **[uses] rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_SECURITY``,
* **[uses] rte_eth_txconf,rte_eth_txmode**:
``offloads:RTE_ETH_TX_OFFLOAD_SECURITY``.
-* **[uses] mbuf**: ``mbuf.l2_len``.
+* **[uses] mbuf**: ``mbuf.l2_len``, ``mbuf.l3_len``, ``mbuf.ol_flags``.
* **[implements] rte_security_ops**: ``session_create``, ``session_update``,
``session_stats_get``, ``session_destroy``, ``set_pkt_metadata``,
``get_userdata``,
``capabilities_get``.
diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
index 3d6ddd6..b62a7c6 100644
--- a/lib/mbuf/rte_mbuf_core.h
+++ b/lib/mbuf/rte_mbuf_core.h
@@ -267,7 +267,8 @@ extern "C" {
/**
* Request security offload processing on the TX packet.
* To use Tx security offload, the user needs to fill l2_len in mbuf
- * indicating L2 header size and where L3 header starts.
+ * indicating L2 header size and where L3 header starts. Similarly,
+ * l3_len should also be filled along with ol_flags reflecting current L3 type.
*/
#define RTE_MBUF_F_TX_SEC_OFFLOAD (1ULL << 43)
#define PKT_TX_SEC_OFFLOAD RTE_DEPRECATED(PKT_TX_SEC_OFFLOAD) \
--
2.8.4
[PATCH v2 2/5] security: clarify L2 header requirement for outbound inline
Clarify that for Outbound Inline IPsec processing, L2 header needs to be up to date with ether type which will be applicable post IPsec processing as the IPsec offload only touches L3 and above. Signed-off-by: Nithin Dabilpuram --- doc/guides/prog_guide/rte_security.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst index 72ca0bd..be158f6 100644 --- a/doc/guides/prog_guide/rte_security.rst +++ b/doc/guides/prog_guide/rte_security.rst @@ -146,7 +146,9 @@ adding the relevant protocol headers and encrypting the data before sending the packet out. The software should make sure that the buffer has required head room and tail room for any protocol header addition. The software may also do early fragmentation if the resultant packet is expected -to cross the MTU size. +to cross the MTU size. The software should also make sure that L2 header contents +are updated with the final L2 header which is expected post IPsec processing as +the IPsec offload will only update L3 and above in egress path. .. note:: -- 2.8.4
[PATCH v2 3/5] net/cnxk: remove L2 header update for outbound inline pkts
Remove L2 header update for outbound inline packets as
application is already taking care of the same.
Signed-off-by: Nithin Dabilpuram
---
drivers/net/cnxk/cn10k_tx.h | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/net/cnxk/cn10k_tx.h b/drivers/net/cnxk/cn10k_tx.h
index ea13866..4bd47ef 100644
--- a/drivers/net/cnxk/cn10k_tx.h
+++ b/drivers/net/cnxk/cn10k_tx.h
@@ -362,15 +362,6 @@ cn10k_nix_prep_sec_vec(struct rte_mbuf *m, uint64x2_t
*cmd0, uint64x2_t *cmd1,
dptr += l2_len;
- if (sess_priv.mode == ROC_IE_SA_MODE_TUNNEL) {
- if (sess_priv.outer_ip_ver == ROC_IE_SA_IP_VERSION_4)
- *((uint16_t *)(dptr - 2)) =
- rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
- else
- *((uint16_t *)(dptr - 2)) =
- rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV6);
- }
-
ucode_cmd[1] = dptr;
ucode_cmd[2] = dptr;
@@ -490,14 +481,6 @@ cn10k_nix_prep_sec(struct rte_mbuf *m, uint64_t *cmd,
uintptr_t *nixtx_addr,
dptr += l2_len;
- if (sess_priv.mode == ROC_IE_SA_MODE_TUNNEL) {
- if (sess_priv.outer_ip_ver == ROC_IE_SA_IP_VERSION_4)
- *((uint16_t *)(dptr - 2)) =
- rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
- else
- *((uint16_t *)(dptr - 2)) =
- rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV6);
- }
ucode_cmd[1] = dptr;
ucode_cmd[2] = dptr;
--
2.8.4
[PATCH v2 4/5] app/test: update L2 header based on tunnel IP version
Update L2 header based on tunnel IP version.
Signed-off-by: Nithin Dabilpuram
---
app/test/test_security_inline_proto.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/app/test/test_security_inline_proto.c
b/app/test/test_security_inline_proto.c
index 5f26a04..b282e7d 100644
--- a/app/test/test_security_inline_proto.c
+++ b/app/test/test_security_inline_proto.c
@@ -418,15 +418,29 @@ copy_buf_to_pkt_segs(const uint8_t *buf, unsigned int len,
rte_memcpy(seg_buf, buf + copied, (size_t) len);
}
+static bool
+is_outer_ipv4(struct ipsec_test_data *td)
+{
+ bool outer_ipv4;
+
+ if (td->ipsec_xform.direction == RTE_SECURITY_IPSEC_SA_DIR_INGRESS ||
+ td->ipsec_xform.mode == RTE_SECURITY_IPSEC_SA_MODE_TRANSPORT)
+ outer_ipv4 = (((td->input_text.data[0] & 0xF0) >> 4) ==
IPVERSION);
+ else
+ outer_ipv4 = (td->ipsec_xform.tunnel.type ==
RTE_SECURITY_IPSEC_TUNNEL_IPV4);
+ return outer_ipv4;
+}
+
static inline struct rte_mbuf *
-init_packet(struct rte_mempool *mp, const uint8_t *data, unsigned int len)
+init_packet(struct rte_mempool *mp, const uint8_t *data, unsigned int len,
bool outer_ipv4)
{
struct rte_mbuf *pkt;
pkt = rte_pktmbuf_alloc(mp);
if (pkt == NULL)
return NULL;
- if (((data[0] & 0xF0) >> 4) == IPVERSION) {
+
+ if (outer_ipv4) {
rte_memcpy(rte_pktmbuf_append(pkt, RTE_ETHER_HDR_LEN),
&dummy_ipv4_eth_hdr, RTE_ETHER_HDR_LEN);
pkt->l3_len = sizeof(struct rte_ipv4_hdr);
@@ -711,6 +725,7 @@ test_ipsec_with_reassembly(struct reassembly_vector *vector,
struct rte_security_ctx *ctx;
unsigned int i, nb_rx = 0, j;
uint32_t ol_flags;
+ bool outer_ipv4;
int ret = 0;
burst_sz = vector->burst ? ENCAP_DECAP_BURST_SZ : 1;
@@ -740,11 +755,15 @@ test_ipsec_with_reassembly(struct reassembly_vector
*vector,
memset(tx_pkts_burst, 0, sizeof(tx_pkts_burst[0]) * nb_tx);
memset(rx_pkts_burst, 0, sizeof(rx_pkts_burst[0]) * nb_tx);
+ memcpy(&sa_data, vector->sa_data, sizeof(struct ipsec_test_data));
+ sa_data.ipsec_xform.direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS;
+ outer_ipv4 = is_outer_ipv4(&sa_data);
+
for (i = 0; i < nb_tx; i += vector->nb_frags) {
for (j = 0; j < vector->nb_frags; j++) {
tx_pkts_burst[i+j] = init_packet(mbufpool,
vector->frags[j]->data,
- vector->frags[j]->len);
+ vector->frags[j]->len,
outer_ipv4);
if (tx_pkts_burst[i+j] == NULL) {
ret = -1;
printf("\n packed init failed\n");
@@ -963,6 +982,7 @@ test_ipsec_inline_proto_process(struct ipsec_test_data *td,
int nb_rx = 0, nb_sent;
uint32_t ol_flags;
int i, j = 0, ret;
+ bool outer_ipv4;
memset(rx_pkts_burst, 0, sizeof(rx_pkts_burst[0]) * nb_pkts);
@@ -994,9 +1014,11 @@ test_ipsec_inline_proto_process(struct ipsec_test_data
*td,
if (ret)
goto out;
}
+ outer_ipv4 = is_outer_ipv4(td);
+
for (i = 0; i < nb_pkts; i++) {
tx_pkts_burst[i] = init_packet(mbufpool, td->input_text.data,
- td->input_text.len);
+ td->input_text.len, outer_ipv4);
if (tx_pkts_burst[i] == NULL) {
while (i--)
rte_pktmbuf_free(tx_pkts_burst[i]);
@@ -1194,6 +1216,7 @@ test_ipsec_inline_proto_process_with_esn(struct
ipsec_test_data td[],
struct rte_security_session *ses;
struct rte_security_ctx *ctx;
uint32_t ol_flags;
+ bool outer_ipv4;
int i, ret;
if (td[0].aead) {
@@ -1224,10 +1247,11 @@ test_ipsec_inline_proto_process_with_esn(struct
ipsec_test_data td[],
if (ret)
goto out;
}
+ outer_ipv4 = is_outer_ipv4(td);
for (i = 0; i < nb_pkts; i++) {
tx_pkt = init_packet(mbufpool, td[i].input_text.data,
- td[i].input_text.len);
+ td[i].input_text.len, outer_ipv4);
if (tx_pkt == NULL) {
ret = TEST_FAILED;
goto out;
--
2.8.4
[PATCH v2 5/5] examples/ipsec-secgw: update ether type using tunnel info
Update ether type for outbound SA processing based on tunnel header
information in both NEON functions for poll mode and event mode worker
functions.
Signed-off-by: Nithin Dabilpuram
---
examples/ipsec-secgw/ipsec_neon.h | 41 +
examples/ipsec-secgw/ipsec_worker.c | 30 +++
2 files changed, 49 insertions(+), 22 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec_neon.h
b/examples/ipsec-secgw/ipsec_neon.h
index 3f2d0a0..9c0498b 100644
--- a/examples/ipsec-secgw/ipsec_neon.h
+++ b/examples/ipsec-secgw/ipsec_neon.h
@@ -18,12 +18,13 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
*/
static inline void
processx4_step3(struct rte_mbuf *pkts[FWDSTEP], uint16_t dst_port[FWDSTEP],
- uint64_t tx_offloads, bool ip_cksum, uint8_t *l_pkt)
+ uint64_t tx_offloads, bool ip_cksum, bool is_ipv4, uint8_t
*l_pkt)
{
uint32x4_t te[FWDSTEP];
uint32x4_t ve[FWDSTEP];
uint32_t *p[FWDSTEP];
struct rte_mbuf *pkt;
+ uint32_t val;
uint8_t i;
for (i = 0; i < FWDSTEP; i++) {
@@ -38,7 +39,15 @@ processx4_step3(struct rte_mbuf *pkts[FWDSTEP], uint16_t
dst_port[FWDSTEP],
te[i] = vld1q_u32(p[i]);
/* Update last 4 bytes */
- ve[i] = vsetq_lane_u32(vgetq_lane_u32(te[i], 3), ve[i], 3);
+ val = vgetq_lane_u32(te[i], 3);
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ val &= 0xUL << 16;
+ val |= rte_cpu_to_be_16(is_ipv4 ? RTE_ETHER_TYPE_IPV4 :
RTE_ETHER_TYPE_IPV6);
+#else
+ val &= 0xUL;
+ val |= rte_cpu_to_be_16(is_ipv4 ? RTE_ETHER_TYPE_IPV4 :
RTE_ETHER_TYPE_IPV6) << 16;
+#endif
+ ve[i] = vsetq_lane_u32(val, ve[i], 3);
vst1q_u32(p[i], ve[i]);
if (ip_cksum) {
@@ -64,10 +73,11 @@ processx4_step3(struct rte_mbuf *pkts[FWDSTEP], uint16_t
dst_port[FWDSTEP],
*/
static inline void
process_packet(struct rte_mbuf *pkt, uint16_t *dst_port, uint64_t tx_offloads,
- bool ip_cksum, uint8_t *l_pkt)
+ bool ip_cksum, bool is_ipv4, uint8_t *l_pkt)
{
struct rte_ether_hdr *eth_hdr;
uint32x4_t te, ve;
+ uint32_t val;
/* Check if it is a large packet */
if (pkt->pkt_len - RTE_ETHER_HDR_LEN > mtu_size)
@@ -78,7 +88,15 @@ process_packet(struct rte_mbuf *pkt, uint16_t *dst_port,
uint64_t tx_offloads,
te = vld1q_u32((uint32_t *)eth_hdr);
ve = vreinterpretq_u32_s32(val_eth[dst_port[0]]);
- ve = vcopyq_laneq_u32(ve, 3, te, 3);
+ val = vgetq_lane_u32(te, 3);
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ val &= 0xUL << 16;
+ val |= rte_cpu_to_be_16(is_ipv4 ? RTE_ETHER_TYPE_IPV4 :
RTE_ETHER_TYPE_IPV6);
+#else
+ val &= 0xUL;
+ val |= rte_cpu_to_be_16(is_ipv4 ? RTE_ETHER_TYPE_IPV4 :
RTE_ETHER_TYPE_IPV6) << 16;
+#endif
+ ve = vsetq_lane_u32(val, ve, 3);
vst1q_u32((uint32_t *)eth_hdr, ve);
if (ip_cksum) {
@@ -223,14 +241,14 @@ send_multi_pkts(struct rte_mbuf **pkts, uint16_t
dst_port[MAX_PKT_BURST],
lp = pnum;
lp[0] = 1;
- processx4_step3(pkts, dst_port, tx_offloads, ip_cksum, &l_pkt);
+ processx4_step3(pkts, dst_port, tx_offloads, ip_cksum, is_ipv4,
&l_pkt);
/* dp1: */
dp1 = vld1q_u16(dst_port);
for (i = FWDSTEP; i != k; i += FWDSTEP) {
- processx4_step3(&pkts[i], &dst_port[i], tx_offloads,
- ip_cksum, &l_pkt);
+ processx4_step3(&pkts[i], &dst_port[i], tx_offloads,
ip_cksum, is_ipv4,
+ &l_pkt);
/*
* dp2:
@@ -268,20 +286,17 @@ send_multi_pkts(struct rte_mbuf **pkts, uint16_t
dst_port[MAX_PKT_BURST],
/* Process up to last 3 packets one by one. */
switch (nb_rx % FWDSTEP) {
case 3:
- process_packet(pkts[i], dst_port + i, tx_offloads, ip_cksum,
- &l_pkt);
+ process_packet(pkts[i], dst_port + i, tx_offloads, ip_cksum,
is_ipv4, &l_pkt);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, i);
i++;
/* fallthrough */
case 2:
- process_packet(pkts[i], dst_port + i, tx_offloads, ip_cksum,
- &l_pkt);
+ process_packet(pkts[i], dst_port + i, tx_offloads, ip_cksum,
is_ipv4, &l_pkt);
GROUP_PORT_STEP(dlp, dst_port, lp, pnum, i);
i++;
/* fallthrough */
case 1:
- process_packet(pkts[i], dst_port + i, tx_offloads, ip_cksum,
- &l_pkt);
+ process_packet(pkts[i], dst_port + i, tx_offloads, ip_cksum,
is_ipv4, &l_pkt);
GROUP_PORT_STEP(dl
[PATCH v2] net/vhost: support asynchronous data path
Vhost asynchronous data-path offloads packet copy from the CPU
to the DMA engine. As a result, large packet copy can be accelerated
by the DMA engine, and vhost can free CPU cycles for higher level
functions.
In this patch, we enable asynchronous data-path for vhostpmd.
Asynchronous data path is enabled per tx/rx queue, and users need
to specify the DMA device used by the tx/rx queue. Each tx/rx queue
only supports to use one DMA device, but one DMA device can be shared
among multiple tx/rx queues of different vhostpmd ports.
Two PMD parameters are added:
- dmas: specify the used DMA device for a tx/rx queue.
(Default: no queues enable asynchronous data path)
- dma-ring-size: DMA ring size.
(Default: 4096).
Here is an example:
--vdev
'eth_vhost0,iface=./s0,dmas=[txq0@:00.01.0;rxq0@:00.01.1],dma-ring-size=4096'
Signed-off-by: Jiayu Hu
Signed-off-by: Yuan Wang
Signed-off-by: Wenwu Ma
---
v2:
- add missing file
- hide async_tx_poll_completed
- change default DMA ring size to 4096
---
drivers/net/vhost/meson.build | 1 +
drivers/net/vhost/rte_eth_vhost.c | 494 --
drivers/net/vhost/rte_eth_vhost.h | 11 +
drivers/net/vhost/vhost_testpmd.c | 65
4 files changed, 538 insertions(+), 33 deletions(-)
create mode 100644 drivers/net/vhost/vhost_testpmd.c
diff --git a/drivers/net/vhost/meson.build b/drivers/net/vhost/meson.build
index f481a3a4b8..22a0ab3a58 100644
--- a/drivers/net/vhost/meson.build
+++ b/drivers/net/vhost/meson.build
@@ -9,4 +9,5 @@ endif
deps += 'vhost'
sources = files('rte_eth_vhost.c')
+testpmd_sources = files('vhost_testpmd.c')
headers = files('rte_eth_vhost.h')
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index 7e512d94bf..18fafb5913 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include "rte_eth_vhost.h"
@@ -36,8 +38,13 @@ enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
#define ETH_VHOST_LINEAR_BUF "linear-buffer"
#define ETH_VHOST_EXT_BUF "ext-buffer"
#define ETH_VHOST_LEGACY_OL_FLAGS "legacy-ol-flags"
+#define ETH_VHOST_DMA_ARG "dmas"
+#define ETH_VHOST_DMA_RING_SIZE"dma-ring-size"
#define VHOST_MAX_PKT_BURST 32
+#define INVALID_DMA_ID -1
+#define DEFAULT_DMA_RING_SIZE 4096
+
static const char *valid_arguments[] = {
ETH_VHOST_IFACE_ARG,
ETH_VHOST_QUEUES_ARG,
@@ -48,6 +55,8 @@ static const char *valid_arguments[] = {
ETH_VHOST_LINEAR_BUF,
ETH_VHOST_EXT_BUF,
ETH_VHOST_LEGACY_OL_FLAGS,
+ ETH_VHOST_DMA_ARG,
+ ETH_VHOST_DMA_RING_SIZE,
NULL
};
@@ -79,8 +88,39 @@ struct vhost_queue {
struct vhost_stats stats;
int intr_enable;
rte_spinlock_t intr_lock;
+
+ /* Flag of enabling async data path */
+ bool async_register;
+ /* DMA device ID */
+ int16_t dma_id;
+ /**
+* For a Rx queue, "txq" points to its peer Tx queue.
+* For a Tx queue, "txq" is never used.
+*/
+ struct vhost_queue *txq;
+ /* Array to keep DMA completed packets */
+ struct rte_mbuf *cmpl_pkts[VHOST_MAX_PKT_BURST];
};
+struct dma_input_info {
+ int16_t dmas[RTE_MAX_QUEUES_PER_PORT * 2];
+ uint16_t dma_ring_size;
+};
+
+static int16_t configured_dmas[RTE_DMADEV_DEFAULT_MAX];
+static int dma_count;
+
+/**
+ * By default, its Rx path to call rte_vhost_poll_enqueue_completed() for
enqueue operations.
+ * However, Rx function is never been called in testpmd "txonly" mode, thus
causing virtio
+ * cannot receive DMA completed packets. To make txonly mode work correctly,
we provide a
+ * command in testpmd to call rte_vhost_poll_enqueue_completed() in Tx path.
+ *
+ * When set async_tx_poll_completed to true, Tx path calls
rte_vhost_poll_enqueue_completed();
+ * otherwise, Rx path calls it.
+ */
+bool async_tx_poll_completed;
+
struct pmd_internal {
rte_atomic32_t dev_attached;
char *iface_name;
@@ -93,6 +133,10 @@ struct pmd_internal {
bool vlan_strip;
bool rx_sw_csum;
bool tx_sw_csum;
+ struct {
+ int16_t dma_id;
+ bool async_register;
+ } queue_dmas[RTE_MAX_QUEUES_PER_PORT * 2];
};
struct internal_list {
@@ -123,6 +167,17 @@ struct rte_vhost_vring_state {
static struct rte_vhost_vring_state *vring_states[RTE_MAX_ETHPORTS];
+static bool
+dma_is_configured(int16_t dma_id)
+{
+ int i;
+
+ for (i = 0; i < dma_count; i++)
+ if (configured_dmas[i] == dma_id)
+ return true;
+ return false;
+}
+
static int
vhost_dev_xstats_reset(struct rte_eth_dev *dev)
{
@@ -395,6 +450,17 @@ vhost_dev_rx_sw_csum(struct rte_mbuf *mbuf)
mbuf->ol_flags |= RTE_MBUF_F_RX_L4_CKSUM_GOOD;
}
+static inline void
+vhost_tx_free_completed(uint16_
[PATCH] sched:subport field is unused in hqos profile.
From: Megha Ajmera --- examples/qos_sched/profile.cfg | 2 -- 1 file changed, 2 deletions(-) diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg index d4b21c0170..8da5777538 100644 --- a/examples/qos_sched/profile.cfg +++ b/examples/qos_sched/profile.cfg @@ -26,8 +26,6 @@ number of subports per port = 1 number of pipes per subport = 4096 queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64 -subport 0-8 = 0; These subports are configured with subport profile 0 - [subport profile 0] tb rate = 125000 ; Bytes per second tb size = 100 ; Bytes -- 2.25.1
[PATCH] app/test: fix LACP handshake overtime
Increase the loop count so that there is a longer
threshold time for the LACP handshake process.
Fixes: 5e41ab250dfa ("app/test: unit tests for bonding mode 4")
Cc: sta...@dpdk.org
Signed-off-by: Ke Zhang
---
app/test/test_link_bonding_mode4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test/test_link_bonding_mode4.c
b/app/test/test_link_bonding_mode4.c
index d9b9c323c7..bfdd18cdd1 100644
--- a/app/test/test_link_bonding_mode4.c
+++ b/app/test/test_link_bonding_mode4.c
@@ -613,7 +613,7 @@ bond_handshake(void)
/* Exchange LACP frames */
all_slaves_done = 0;
- for (i = 0; i < 30 && all_slaves_done == 0; ++i) {
+ for (i = 0; i < 60 && all_slaves_done == 0; ++i) {
rte_delay_ms(delay);
all_slaves_done = 1;
--
2.25.1
[PATCH] sched: Fix subport profile id not set correctly.
In rte_sched_subport_config() API, subport_profile_id is not set correctly. Signed-off-by: Megha Ajmera --- lib/sched/rte_sched.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c index 599c7e9536..09f855a04b 100644 --- a/lib/sched/rte_sched.c +++ b/lib/sched/rte_sched.c @@ -1263,8 +1263,6 @@ rte_sched_subport_config(struct rte_sched_port *port, n_subports++; - subport_profile_id = 0; - /* Port */ port->subports[subport_id] = s; -- 2.25.1
[PATCH] sched: subport field is unused in hqos profile
Signed-off-by: Megha Ajmera --- examples/qos_sched/profile.cfg | 2 -- 1 file changed, 2 deletions(-) diff --git a/examples/qos_sched/profile.cfg b/examples/qos_sched/profile.cfg index d4b21c0170..8da5777538 100644 --- a/examples/qos_sched/profile.cfg +++ b/examples/qos_sched/profile.cfg @@ -26,8 +26,6 @@ number of subports per port = 1 number of pipes per subport = 4096 queue sizes = 64 64 64 64 64 64 64 64 64 64 64 64 64 -subport 0-8 = 0; These subports are configured with subport profile 0 - [subport profile 0] tb rate = 125000 ; Bytes per second tb size = 100 ; Bytes -- 2.25.1
RE: [PATCH v2] app/testpmd: add throughput stats for forward streams
> -Original Message- > From: Ferruh Yigit > Sent: Tuesday, August 16, 2022 17:33 > To: Guo, Junfeng ; Singh, Aman Deep > ; Zhang, Qi Z ; Wu, > Jingjing ; Xing, Beilei > Cc: dev@dpdk.org; Wang, Xiao W ; Honnappa > Nagarahalli > Subject: Re: [PATCH v2] app/testpmd: add throughput stats for forward > streams > > On 8/11/2022 7:57 AM, Guo, Junfeng wrote: > > > > > >> -Original Message- > >> From: Singh, Aman Deep > >> Sent: Friday, June 17, 2022 00:40 > >> To: Guo, Junfeng ; Zhang, Qi Z > >> ; Wu, Jingjing ; Xing, > >> Beilei > >> Cc: dev@dpdk.org; Wang, Xiao W > >> Subject: Re: [PATCH v2] app/testpmd: add throughput stats for > >> forward streams > >> > >> Hi Junfeng, > >> > >> Thanks for the patch. > >> > >> > >> On 6/6/2022 3:09 PM, Junfeng Guo wrote: > >>> 1. add throughput statistics (in pps) for forward streams. > >>> 2. display the forward statistics for every forward stream. > >>> > >>> v2: > >>> add parameter descriptions and fix commit title. > >>> > >>> Signed-off-by: Xiao Wang > >>> Signed-off-by: Junfeng Guo > >>> --- > >>> > >> We do have per port Rx/Tx pps in display stats. > >> For per forward stream we can enable "--record-burst-stats". > >> With it we can get per fwd stream Rx/Tx pps. > >> > >> Please check if this patch is adding any additional functionality. > > > > Sorry for the late reply. > > Seems that "--record-burst-stats" could only show the stats of Rx/Tx > bursts. > > > > Hi Junfeng, > > What is the impact of this change to the performance? > > And what do you think enabling it with an command, > like existing "set record-*" ones? Thanks for your advice! We will consider about this method, and also the performance impact. Thanks a lot! Regards, Junfeng Guo > > > Actually this patch can enable the throughput stats, which has not been > supported in current testpmd. > > So we hope this functionality could be added. > > Thanks! > > > >> > >> > >
RE: [RFC 1/2] vhost: add ingress API for port mirroring datapath
Hi, > -Original Message- > From: Stephen Hemminger > Sent: Sunday, August 14, 2022 10:58 PM > To: Jiang, Cheng1 > Cc: maxime.coque...@redhat.com; Xia, Chenbo ; > dev@dpdk.org; Hu, Jiayu ; Ding, Xuan > ; Ma, WenwuX ; Wang, > YuanX ; Yang, YvonneX > Subject: Re: [RFC 1/2] vhost: add ingress API for port mirroring datapath > > On Sun, 14 Aug 2022 12:49:19 + > Cheng Jiang wrote: > > > From: Wenwu Ma > > > > Similar to the port mirroring function on the switch or router, this > > patch also implements an ingress function on the Vhost lib. When data > > is sent to a front-end, it will also send the data to its mirror > > front-end. > > > > Signed-off-by: Cheng Jiang > > Signed-off-by: Wenwu Ma > > We already have rte_flow, packet capture, and rx/tx callbacks. > This seems like re-invention. Sorry that I didn't make it clear in the v1 commit message. This port mirror function is based on async vhost which is accelerated by DMA device. Compared with other mirror implements: 1. It's targeted for vhost. 2. The performance is really good. Its use scenario is to let one front-end(mirror-VM) monitor the traffic of another front-end(VM). It's different from the things you mentioned above. So, IMO I don't think it's re-invention. Thanks, Cheng
