[PATCH 1/2] config: allow AVX512 instructions to be used with MSVC

2025-02-27 Thread Andre Muezerie
Up to now MSVC has being used with the default mode, which uses SSE2
instructions for scalar floating-point and vector calculations.
https://learn.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-170

This patch allows users to specify the CPU for which the generated
code should be optimized for in the same way it's done for GCC: by
passing the CPU name.
When no explicit CPU name is passed, 'native' is assumed (like it
happens with GCC) and the code will be optimized for the same CPU
type used to compile the code.

MSVC does not provide this functionality natively, so logic was
added to a new meson.build file under config/x86/msvc to handle
these differences, detecting which
instruction sets are supported by the CPU(s), passing the best
options to MSVC and setting the correct macros (like __AVX512F__)
so that the DPDK code can rely on them like it is done with GCC.

Signed-off-by: Andre Muezerie 
---
 config/x86/meson.build  |  87 +--
 config/x86/msvc/meson.build | 287 
 lib/acl/meson.build |   8 +-
 lib/member/meson.build  |  11 +-
 4 files changed, 343 insertions(+), 50 deletions(-)
 create mode 100644 config/x86/msvc/meson.build

diff --git a/config/x86/meson.build b/config/x86/meson.build
index 47a5b0c04a..8a88280998 100644
--- a/config/x86/meson.build
+++ b/config/x86/meson.build
@@ -1,6 +1,50 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2017-2020 Intel Corporation
 
+dpdk_conf.set('RTE_ARCH_X86', 1)
+if dpdk_conf.get('RTE_ARCH_64')
+dpdk_conf.set('RTE_ARCH_X86_64', 1)
+dpdk_conf.set('RTE_ARCH', 'x86_64')
+else
+dpdk_conf.set('RTE_ARCH_I686', 1)
+dpdk_conf.set('RTE_ARCH', 'i686')
+endif
+
+dpdk_conf.set('RTE_CACHE_LINE_SIZE', 64)
+dpdk_conf.set('RTE_MAX_LCORE', 128)
+
+epyc_zen_cores = {
+'__znver5__':768,
+'__znver4__':512,
+'__znver3__':256,
+'__znver2__':256,
+'__znver1__':128
+}
+
+cpu_instruction_set = get_option('cpu_instruction_set')
+if cpu_instruction_set == 'native'
+foreach m:epyc_zen_cores.keys()
+if cc.get_define(m, args: machine_args) != ''
+dpdk_conf.set('RTE_MAX_LCORE', epyc_zen_cores[m])
+break
+endif
+endforeach
+else
+foreach m:epyc_zen_cores.keys()
+if m.contains(cpu_instruction_set)
+dpdk_conf.set('RTE_MAX_LCORE', epyc_zen_cores[m])
+break
+endif
+endforeach
+endif
+
+dpdk_conf.set('RTE_MAX_NUMA_NODES', 32)
+
+if is_ms_compiler
+subdir('msvc')
+subdir_done()
+endif
+
 # get binutils version for the workaround of Bug 97
 binutils_ok = true
 if is_linux or cc.get_id() == 'gcc'
@@ -14,7 +58,8 @@ if is_linux or cc.get_id() == 'gcc'
 endif
 endif
 
-cc_avx512_flags = ['-mavx512f', '-mavx512vl', '-mavx512dq', '-mavx512bw']
+cc_avx2_flags = ['-mavx2']
+cc_avx512_flags = ['-mavx512f', '-mavx512vl', '-mavx512dq', '-mavx512bw', 
'-mavx512cd']
 cc_has_avx512 = false
 target_has_avx512 = false
 if (binutils_ok and cc.has_multi_arguments(cc_avx512_flags)
@@ -82,43 +127,3 @@ foreach f:optional_flags
 compile_time_cpuflags += ['RTE_CPUFLAG_' + f]
 endif
 endforeach
-
-
-dpdk_conf.set('RTE_ARCH_X86', 1)
-if dpdk_conf.get('RTE_ARCH_64')
-dpdk_conf.set('RTE_ARCH_X86_64', 1)
-dpdk_conf.set('RTE_ARCH', 'x86_64')
-else
-dpdk_conf.set('RTE_ARCH_I686', 1)
-dpdk_conf.set('RTE_ARCH', 'i686')
-endif
-
-dpdk_conf.set('RTE_CACHE_LINE_SIZE', 64)
-dpdk_conf.set('RTE_MAX_LCORE', 128)
-
-epyc_zen_cores = {
-'__znver5__':768,
-'__znver4__':512,
-'__znver3__':256,
-'__znver2__':256,
-'__znver1__':128
-}
-
-cpu_instruction_set = get_option('cpu_instruction_set')
-if cpu_instruction_set == 'native'
-foreach m:epyc_zen_cores.keys()
-if cc.get_define(m, args: machine_args) != ''
-dpdk_conf.set('RTE_MAX_LCORE', epyc_zen_cores[m])
-break
-endif
-endforeach
-else
-foreach m:epyc_zen_cores.keys()
-if m.contains(cpu_instruction_set)
-dpdk_conf.set('RTE_MAX_LCORE', epyc_zen_cores[m])
-break
-endif
-endforeach
-endif
-
-dpdk_conf.set('RTE_MAX_NUMA_NODES', 32)
diff --git a/config/x86/msvc/meson.build b/config/x86/msvc/meson.build
new file mode 100644
index 00..646c9a8515
--- /dev/null
+++ b/config/x86/msvc/meson.build
@@ -0,0 +1,287 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2025 Microsoft Corporation
+
+cc_avx2_flags = ['/arch:AVX2']
+cc_avx512_flags = ['/arch:AVX512']
+cc_has_avx512 = true
+
+cpuid_code = '''
+#include 
+#include 
+#include 
+
+uint32_t f1_ECX = 0;
+uint32_t f1_EDX = 0;
+uint32_t f7_EBX = 0;
+uint32_t f7_ECX = 0;
+
+void get_support_flags()
+{
+int ids_max;
+int data[4];
+
+/*
+ * Calling __cpuid with 0x0 as the function_id argument
+ * gets the number of the highest valid function ID.
+ */
+__cpuid(data, 0);
+

[PATCH 0/2] allow AVX512 instructions to be used with MSVC

2025-02-27 Thread Andre Muezerie
Up to now MSVC has being used with the default mode, which uses SSE2
instructions for scalar floating-point and vector calculations.
https://learn.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-170

This patchset allows users to specify the CPU for which the generated
code should be optimized for in the same way it's done for GCC: by
passing the CPU name. When no name is provided 'native' is assumed
meaning that the code should be optimized for the machine compiling
the code.

MSVC does not provide this functionality natively, so logic was
added. This additional logic relies on a table which stores instruction
set availability (like AXV512F) for different CPUs.

To make it easier to update this table a new devtool was also added.

Andre Muezerie (2):
  config: allow AVX512 instructions to be used with MSVC
  devtools/dump-cpu-flags: add tool to update CPU flags table

 config/x86/meson.build |  87 ---
 config/x86/msvc/meson.build| 287 +
 devtools/dump-cpu-flags/README.md  |  25 ++
 devtools/dump-cpu-flags/cpu-names.txt  | 120 +
 devtools/dump-cpu-flags/dump-cpu-flags.cpp | 119 +
 devtools/dump-cpu-flags/dump-cpu-flags.py  |  41 +++
 lib/acl/meson.build|   8 +-
 lib/member/meson.build |  11 +-
 8 files changed, 648 insertions(+), 50 deletions(-)
 create mode 100644 config/x86/msvc/meson.build
 create mode 100644 devtools/dump-cpu-flags/README.md
 create mode 100644 devtools/dump-cpu-flags/cpu-names.txt
 create mode 100644 devtools/dump-cpu-flags/dump-cpu-flags.cpp
 create mode 100644 devtools/dump-cpu-flags/dump-cpu-flags.py

--
2.48.1.vfs.0.0



[PATCH 2/2] devtools/dump-cpu-flags: add tool to update CPU flags table

2025-02-27 Thread Andre Muezerie
This patchset allows users to specify the CPU for which the generated
code should be optimized for by passing the CPU name.

MSVC does not provide this functionality natively, so logic was
added. This additional logic relies on a table which stores instruction
set availability (like AXV512F) for different CPUs.
To make it easier to update this table a new devtool is introduced
with this patch. The new tool generates the table entries for all CPUs
listed in an input file using a recent version of the compiler, which
has all the information needed. This reduces enormously the amount
of work needed to update the table in msvc/meson.build and makes the
process much less error prone.

Signed-off-by: Andre Muezerie 
---
 devtools/dump-cpu-flags/README.md  |  25 +
 devtools/dump-cpu-flags/cpu-names.txt  | 120 +
 devtools/dump-cpu-flags/dump-cpu-flags.cpp | 119 
 devtools/dump-cpu-flags/dump-cpu-flags.py  |  41 +++
 4 files changed, 305 insertions(+)
 create mode 100644 devtools/dump-cpu-flags/README.md
 create mode 100644 devtools/dump-cpu-flags/cpu-names.txt
 create mode 100644 devtools/dump-cpu-flags/dump-cpu-flags.cpp
 create mode 100644 devtools/dump-cpu-flags/dump-cpu-flags.py

diff --git a/devtools/dump-cpu-flags/README.md 
b/devtools/dump-cpu-flags/README.md
new file mode 100644
index 00..3db69f9f8f
--- /dev/null
+++ b/devtools/dump-cpu-flags/README.md
@@ -0,0 +1,25 @@
+# Generating updated CPU flags
+
+File `config\x86\msvc\meson.build` has a table with flags indicating 
instruction set support for a variety of CPU types.
+
+Script `dump-cpu-flags.py` can be used to generate updated entries for this 
table.
+
+The CPU names are stored in file `cpu-names.txt`, which is consumed by 
`dump-cpu-flags.py`. The formatting used in that file is described at the top 
of the file itself.
+
+The script relies on the information embedded in the g++ compiler. This means 
that an updated table can automatically be generated by switching to a newer 
version of the compiler. This avoids the need to manually edit the entries, 
which is error prone. With the script the table entries can just copied and 
pasted into `meson.build`. The only thing that might need to be done is adding 
new CPU names to cpu-names.txt, when new CPUs are released.
+
+**NOTE**: CPUs not known to the compiler will result in errors, which can be 
ignored (`dump-cpu-flags.py` will ignore these errors and continue). For best 
results use the latest g++ compiler available.
+
+Below is a sample output, where an error was logged because the compiler did 
not know about a CPU named ‘raptorlake’.
+
+```sh
+$ ./dump-cpu-flags.py
+   'x86-64-v2': [],
+   'x86-64-v3': ['AVX', 'AVX2'],
+   'x86-64-v4': ['AVX', 'AVX2', 'AVX512F', 'AVX512VL', 'AVX512BW', 
'AVX512DQ', 'AVX512CD'],
+   'alderlake': ['AVX', 'PCLMUL', 'RDRND', 'AVX2', 'RDSEED', 'AES', 
'VPCLMULQDQ', 'GFNI'],
+cc1plus: error: bad value (‘raptorlake’) for ‘-march=’ switch
+cc1plus: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem 
corei7 westmere sandybridge...
+  'silvermont': ['PCLMUL', 'RDRND'],
+ 'slm': ['PCLMUL', 'RDRND'],
+```
\ No newline at end of file
diff --git a/devtools/dump-cpu-flags/cpu-names.txt 
b/devtools/dump-cpu-flags/cpu-names.txt
new file mode 100644
index 00..5ceaf05c0d
--- /dev/null
+++ b/devtools/dump-cpu-flags/cpu-names.txt
@@ -0,0 +1,120 @@
+# This file is consumed by dump-cpu-flags.py. It should contain CPU names,
+# one per line. When the given CPU has a 32 bit architecture, it must be
+# indicated so by appending ", 32" to the line.
+# Always use the latest compiler available, otherwise it might not know
+# about some CPUs listed here.
+# The latest CPU names can be obtained from:
+# https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
+#
+
+x86-64
+x86-64-v2
+x86-64-v3
+x86-64-v4
+i386, 32
+i486, 32
+i586, 32
+pentium, 32
+lakemont, 32
+pentium-mmx, 32
+pentiumpro, 32
+i686, 32
+pentium2, 32
+pentium3, 32
+pentium3m, 32
+pentium-m, 32
+pentium4, 32
+pentium4m, 32
+prescott, 32
+nocona
+core2
+nehalem
+corei7
+westmere
+sandybridge
+corei7-avx
+ivybridge
+core-avx-i
+haswell
+core-avx2
+broadwell
+skylake
+skylake-avx512
+cascadelake
+cannonlake
+cooperlake
+icelake-client
+icelake-server
+tigerlake
+rocketlake
+alderlake
+raptorlake,
+meteorlake,
+gracemont
+arrowlake
+arrowlake-s
+lunarlake
+pantherlake
+sapphirerapids
+emeraldrapids
+graniterapids
+graniterapids-d
+diamondrapids
+bonnell
+atom
+silvermont
+slm
+goldmont
+goldmont-plus
+tremont
+sierraforest
+grandridge
+clearwaterforest
+k6, 32
+k6-2, 32
+k6-3, 32
+athlon, 32
+athlon-tbird, 32
+athlon-4, 32
+athlon-xp, 32
+athlon-mp, 32
+k8
+opteron
+athlon64
+athlon-fx
+k8-sse3
+opteron-sse3
+athlon64-sse3
+amdfam10
+barcelona
+bdver1
+bdver2
+bdver3
+bdver4
+znver1
+znver2
+znver3
+znver4
+znver5
+btver1
+btver2
+winchip-c6, 32
+winchip2, 32
+c3, 32
+c3-2, 32
+c7, 32
+samuel-2, 32
+nehemiah, 32

[v8 5/5] examples/vhost_crypto: support asymmetric crypto

2025-02-27 Thread Gowrishankar Muthukrishnan
Support asymmetric crypto operations.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 doc/guides/sample_app_ug/vhost_crypto.rst |  5 +++
 examples/vhost_crypto/main.c  | 50 +--
 2 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/doc/guides/sample_app_ug/vhost_crypto.rst 
b/doc/guides/sample_app_ug/vhost_crypto.rst
index 7ae7addac4..b00f2bf3ae 100644
--- a/doc/guides/sample_app_ug/vhost_crypto.rst
+++ b/doc/guides/sample_app_ug/vhost_crypto.rst
@@ -33,6 +33,7 @@ Start the vhost_crypto example
--socket-file lcore,PATH
[--zero-copy]
[--guest-polling]
+   [--asymmetric-crypto]
 
 where,
 
@@ -54,6 +55,10 @@ where,
   guest works in polling mode, thus will NOT notify the guest completion of
   processing.
 
+* asymmetric-crypto: the presence of this item means the application
+  can handle the asymmetric crypto requests. When this option is used,
+  symmetric crypto requests can not be handled by the application.
+
 The application requires that crypto devices capable of performing
 the specified crypto operation are available on application initialization.
 This means that HW crypto device/s must be bound to a DPDK driver or
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index b1fe4120b9..8bdfc40c4b 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -59,6 +59,7 @@ struct vhost_crypto_options {
uint32_t nb_los;
uint32_t zero_copy;
uint32_t guest_polling;
+   bool asymmetric_crypto;
 } options;
 
 enum {
@@ -70,6 +71,8 @@ enum {
OPT_ZERO_COPY_NUM,
 #define OPT_POLLING "guest-polling"
OPT_POLLING_NUM,
+#define OPT_ASYM"asymmetric-crypto"
+   OPT_ASYM_NUM,
 };
 
 #define NB_SOCKET_FIELDS   (2)
@@ -202,9 +205,10 @@ vhost_crypto_usage(const char *prgname)
"  --%s ,SOCKET-FILE-PATH\n"
"  --%s (lcore,cdev_id,queue_id)[,(lcore,cdev_id,queue_id)]\n"
"  --%s: zero copy\n"
-   "  --%s: guest polling\n",
+   "  --%s: guest polling\n"
+   "  --%s: asymmetric crypto\n",
prgname, OPT_SOCKET_FILE, OPT_CONFIG,
-   OPT_ZERO_COPY, OPT_POLLING);
+   OPT_ZERO_COPY, OPT_POLLING, OPT_ASYM);
 }
 
 static int
@@ -223,6 +227,8 @@ vhost_crypto_parse_args(int argc, char **argv)
NULL, OPT_ZERO_COPY_NUM},
{OPT_POLLING, no_argument,
NULL, OPT_POLLING_NUM},
+   {OPT_ASYM, no_argument,
+   NULL, OPT_ASYM_NUM},
{NULL, 0, 0, 0}
};
 
@@ -262,6 +268,10 @@ vhost_crypto_parse_args(int argc, char **argv)
options.guest_polling = 1;
break;
 
+   case OPT_ASYM_NUM:
+   options.asymmetric_crypto = true;
+   break;
+
default:
vhost_crypto_usage(prgname);
return -EINVAL;
@@ -376,6 +386,7 @@ vhost_crypto_worker(void *arg)
int callfds[VIRTIO_CRYPTO_MAX_NUM_BURST_VQS];
uint32_t lcore_id = rte_lcore_id();
uint32_t burst_size = MAX_PKT_BURST;
+   enum rte_crypto_op_type cop_type;
uint32_t i, j, k;
uint32_t to_fetch, fetched;
 
@@ -383,9 +394,13 @@ vhost_crypto_worker(void *arg)
 
RTE_LOG(INFO, USER1, "Processing on Core %u started\n", lcore_id);
 
+   cop_type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
+   if (options.asymmetric_crypto)
+   cop_type = RTE_CRYPTO_OP_TYPE_ASYMMETRIC;
+
for (i = 0; i < NB_VIRTIO_QUEUES; i++) {
if (rte_crypto_op_bulk_alloc(info->cop_pool,
-   RTE_CRYPTO_OP_TYPE_SYMMETRIC, ops[i],
+   cop_type, ops[i],
burst_size) < burst_size) {
RTE_LOG(ERR, USER1, "Failed to alloc cops\n");
ret = -1;
@@ -411,12 +426,11 @@ vhost_crypto_worker(void *arg)
fetched);
if (unlikely(rte_crypto_op_bulk_alloc(
info->cop_pool,
-   RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   cop_type,
ops[j], fetched) < fetched)) {
RTE_LOG(ERR, USER1, "Failed realloc\n");
return -1;
}
-
fetched = rte_cryptodev_dequeue_burst(
info->cid, info->qid,
ops_deq[j], RTE_MIN(burst_size,
@@ -477,6 +491,7 @@ m

[v8 4/5] vhost: support asymmetric RSA crypto ops

2025-02-27 Thread Gowrishankar Muthukrishnan
Support asymmetric RSA crypto operations in vhost-user.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 doc/guides/rel_notes/release_25_03.rst |   3 +
 lib/vhost/vhost_crypto.c   | 486 +++--
 lib/vhost/virtio_crypto.h  |  67 
 3 files changed, 521 insertions(+), 35 deletions(-)

diff --git a/doc/guides/rel_notes/release_25_03.rst 
b/doc/guides/rel_notes/release_25_03.rst
index 8867a4bd74..087a407337 100644
--- a/doc/guides/rel_notes/release_25_03.rst
+++ b/doc/guides/rel_notes/release_25_03.rst
@@ -151,6 +151,9 @@ New Features
 
   See the :doc:`../compressdevs/zsda` guide for more details on the new driver.
 
+* **Updated vhost library.**
+
+  Updated vhost library to support RSA crypto operations.
 
 Removed Items
 -
diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index f9d5128af0..06c325cb88 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -55,6 +55,14 @@ RTE_LOG_REGISTER_SUFFIX(vhost_crypto_logtype, crypto, INFO);
  */
 #define vhost_crypto_desc vring_desc
 
+struct vhost_crypto_session {
+   union {
+   struct rte_cryptodev_asym_session *asym;
+   struct rte_cryptodev_sym_session *sym;
+   };
+   enum rte_crypto_op_type type;
+};
+
 static int
 cipher_algo_transform(uint32_t virtio_cipher_algo,
enum rte_crypto_cipher_algorithm *algo)
@@ -207,8 +215,10 @@ struct __rte_cache_aligned vhost_crypto {
 
uint64_t last_session_id;
 
-   uint64_t cache_session_id;
-   struct rte_cryptodev_sym_session *cache_session;
+   uint64_t cache_sym_session_id;
+   struct rte_cryptodev_sym_session *cache_sym_session;
+   uint64_t cache_asym_session_id;
+   struct rte_cryptodev_asym_session *cache_asym_session;
/** socket id for the device */
int socket_id;
 
@@ -335,10 +345,11 @@ transform_chain_param(struct rte_crypto_sym_xform *xforms,
 }
 
 static void
-vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
+vhost_crypto_create_sym_sess(struct vhost_crypto *vcrypto,
VhostUserCryptoSessionParam *sess_param)
 {
struct rte_crypto_sym_xform xform1 = {0}, xform2 = {0};
+   struct vhost_crypto_session *vhost_session;
struct rte_cryptodev_sym_session *session;
int ret;
 
@@ -385,42 +396,277 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
return;
}
 
-   /* insert hash to map */
-   if (rte_hash_add_key_data(vcrypto->session_map,
-   &vcrypto->last_session_id, session) < 0) {
+   vhost_session = rte_zmalloc(NULL, sizeof(*vhost_session), 0);
+   if (vhost_session == NULL) {
+   VC_LOG_ERR("Failed to alloc session memory");
+   goto error_exit;
+   }
+
+   vhost_session->type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
+   vhost_session->sym = session;
+
+   /* insert session to map */
+   if ((rte_hash_add_key_data(vcrypto->session_map,
+   &vcrypto->last_session_id, vhost_session) < 0)) {
VC_LOG_ERR("Failed to insert session to hash table");
+   goto error_exit;
+   }
+
+   VC_LOG_INFO("Session %"PRIu64" created for vdev %i.",
+   vcrypto->last_session_id, vcrypto->dev->vid);
+
+   sess_param->session_id = vcrypto->last_session_id;
+   vcrypto->last_session_id++;
+   return;
+
+error_exit:
+   if (rte_cryptodev_sym_session_free(vcrypto->cid, session) < 0)
+   VC_LOG_ERR("Failed to free session");
+
+   sess_param->session_id = -VIRTIO_CRYPTO_ERR;
+   rte_free(vhost_session);
+}
+
+static int
+tlv_decode(uint8_t *tlv, uint8_t type, uint8_t **data, size_t *data_len)
+{
+   size_t tlen = -EINVAL, len;
+
+   if (tlv[0] != type)
+   return -EINVAL;
 
-   if (rte_cryptodev_sym_session_free(vcrypto->cid, session) < 0)
-   VC_LOG_ERR("Failed to free session");
+   if (tlv[1] == 0x82) {
+   len = (tlv[2] << 8) | tlv[3];
+   *data = &tlv[4];
+   tlen = len + 4;
+   } else if (tlv[1] == 0x81) {
+   len = tlv[2];
+   *data = &tlv[3];
+   tlen = len + 3;
+   } else {
+   len = tlv[1];
+   *data = &tlv[2];
+   tlen = len + 2;
+   }
+
+   *data_len = len;
+   return tlen;
+}
+
+static int
+virtio_crypto_asym_rsa_der_to_xform(uint8_t *der, size_t der_len,
+   struct rte_crypto_asym_xform *xform)
+{
+   uint8_t *n = NULL, *e = NULL, *d = NULL, *p = NULL, *q = NULL, *dp = 
NULL,
+   *dq = NULL, *qinv = NULL, *v = NULL, *tlv;
+   size_t nlen, elen, dlen, plen, qlen, dplen, dqlen, qinvlen, vlen;
+   int len;
+
+   RTE_SET_USED(der_len);
+
+   if (der[0] != 0x30)
+   return -EINVAL;
+
+   if (der[1] == 0x82)
+   tlv = &der[4];
+  

[v2] app/crypto-perf: add RSA support

2025-02-27 Thread Gowrishankar Muthukrishnan
From: Akhil Goyal 

Add RSA support in crypto-perf application.

Signed-off-by: Akhil Goyal 
---
v2:
 - fixed RSA padding type.
---
 app/test-crypto-perf/cperf_ops.c |  69 
 app/test-crypto-perf/cperf_options.h |   4 +
 app/test-crypto-perf/cperf_options_parsing.c |  38 +++-
 app/test-crypto-perf/cperf_test_common.c |   1 +
 app/test-crypto-perf/cperf_test_vectors.c| 175 +++
 app/test-crypto-perf/cperf_test_vectors.h|  23 +++
 app/test-crypto-perf/main.c  |  19 ++
 7 files changed, 328 insertions(+), 1 deletion(-)

diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 6d5f510220..37d06f1dea 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -34,6 +34,40 @@ cperf_set_ops_asym_modex(struct rte_crypto_op **ops,
}
 }
 
+static void
+cperf_set_ops_asym_rsa(struct rte_crypto_op **ops,
+  uint32_t src_buf_offset __rte_unused,
+  uint32_t dst_buf_offset __rte_unused, uint16_t nb_ops,
+  void *sess,
+  const struct cperf_options *options,
+  const struct cperf_test_vector *test_vector __rte_unused,
+  uint16_t iv_offset __rte_unused,
+  uint32_t *imix_idx __rte_unused,
+  uint64_t *tsc_start __rte_unused)
+{
+   uint8_t cipher_buf[4096] = {0};
+   uint16_t i;
+
+   for (i = 0; i < nb_ops; i++) {
+   struct rte_crypto_asym_op *asym_op = ops[i]->asym;
+
+   ops[i]->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
+   asym_op->rsa.op_type = options->asym_op_type;
+   asym_op->rsa.message.data = rsa_plaintext.data;
+   asym_op->rsa.message.length = rsa_plaintext.len;
+   if (options->asym_op_type == RTE_CRYPTO_ASYM_OP_SIGN) {
+   asym_op->rsa.sign.data = cipher_buf;
+   asym_op->rsa.sign.length = options->rsa_data->n.length;
+   } else if (options->asym_op_type == RTE_CRYPTO_ASYM_OP_ENCRYPT) 
{
+   asym_op->rsa.cipher.data = cipher_buf;
+   asym_op->rsa.cipher.length = 
options->rsa_data->n.length;
+   } else {
+   printf("RSA DECRYPT/VERIFY not supported");
+   }
+   rte_crypto_op_attach_asym_session(ops[i], sess);
+   }
+}
+
 static void
 cperf_set_ops_asym_ecdsa(struct rte_crypto_op **ops,
   uint32_t src_buf_offset __rte_unused,
@@ -1040,6 +1074,38 @@ cperf_create_session(struct rte_mempool *sess_mp,
return asym_sess;
}
 
+   if (options->op_type == CPERF_ASYM_RSA) {
+   xform.next = NULL;
+   xform.xform_type = RTE_CRYPTO_ASYM_XFORM_RSA;
+   xform.rsa.padding.type = options->rsa_data->padding;
+   xform.rsa.n.data = options->rsa_data->n.data;
+   xform.rsa.n.length = options->rsa_data->n.length;
+   xform.rsa.e.data = options->rsa_data->e.data;
+   xform.rsa.e.length = options->rsa_data->e.length;
+   xform.rsa.d.data = options->rsa_data->d.data;
+   xform.rsa.d.length = options->rsa_data->d.length;
+   xform.rsa.key_type = options->rsa_data->key_type;
+   if (xform.rsa.key_type == RTE_RSA_KEY_TYPE_QT) {
+   xform.rsa.qt.p.data = options->rsa_data->p.data;
+   xform.rsa.qt.p.length = options->rsa_data->p.length;
+   xform.rsa.qt.q.data = options->rsa_data->q.data;
+   xform.rsa.qt.q.length = options->rsa_data->q.length;
+   xform.rsa.qt.dP.data = options->rsa_data->dp.data;
+   xform.rsa.qt.dP.length = options->rsa_data->dp.length;
+   xform.rsa.qt.dQ.data = options->rsa_data->dq.data;
+   xform.rsa.qt.dQ.length = options->rsa_data->dq.length;
+   xform.rsa.qt.qInv.data = options->rsa_data->qinv.data;
+   xform.rsa.qt.qInv.length = 
options->rsa_data->qinv.length;
+   }
+   ret = rte_cryptodev_asym_session_create(dev_id, &xform,
+   sess_mp, &asym_sess);
+   if (ret < 0) {
+   RTE_LOG(ERR, USER1, "Asym session create failed\n");
+   return NULL;
+   }
+   return asym_sess;
+   }
+
if (options->op_type == CPERF_ASYM_SECP256R1) {
xform.next = NULL;
xform.xform_type = RTE_CRYPTO_ASYM_XFORM_ECDSA;
@@ -1400,6 +1466,9 @@ cperf_get_op_functions(const struct cperf_options 
*options,
case CPERF_ASYM_MODEX:
op_fns->populate_ops = cperf_set_ops_asym_modex;
break;
+   case CPERF_ASYM_RSA:
+   op_fns->populate_ops = cperf_set_ops_asym

[PATCH 2/6] net/netvsc: introduce get_vmbus_device to get the vmbus device

2025-02-27 Thread longli
From: Long Li 

Introduce a function get the vmbus device from hn_data. For secondary
process, the vmbus device is in eth_dev's private region.

Signed-off-by: Long Li 
---
 drivers/net/netvsc/hn_nvs.c | 15 +++
 drivers/net/netvsc/hn_nvs.h |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/drivers/net/netvsc/hn_nvs.c b/drivers/net/netvsc/hn_nvs.c
index 7db82af9f3..fd20e3d06d 100644
--- a/drivers/net/netvsc/hn_nvs.c
+++ b/drivers/net/netvsc/hn_nvs.c
@@ -44,6 +44,21 @@ static const uint32_t hn_nvs_version[] = {
NVS_VERSION_1
 };
 
+struct rte_vmbus_device *get_vmbus_device(struct hn_data *hv)
+{
+   struct rte_vmbus_device *vmbus = hv->vmbus;
+
+   /* For secondary process, vmbus is in the eth_dev private */
+   if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
+   struct rte_eth_dev *dev = &rte_eth_devices[hv->port_id];
+   struct hn_nvs_process_priv *process_priv = dev->process_private;
+
+   vmbus = process_priv->vmbus_dev;
+   }
+
+   return vmbus;
+}
+
 static int hn_nvs_req_send(struct hn_data *hv,
   void *req, uint32_t reqlen)
 {
diff --git a/drivers/net/netvsc/hn_nvs.h b/drivers/net/netvsc/hn_nvs.h
index 88f413f6aa..6a8fcfb3f2 100644
--- a/drivers/net/netvsc/hn_nvs.h
+++ b/drivers/net/netvsc/hn_nvs.h
@@ -221,6 +221,8 @@ voidhn_nvs_handle_vfassoc(struct rte_eth_dev *dev,
  const struct vmbus_chanpkt_hdr *hdr,
  const void *data);
 
+struct rte_vmbus_device *get_vmbus_device(struct hn_data *hv);
+
 static inline int
 hn_nvs_send(struct vmbus_channel *chan, uint16_t flags,
void *nvs_msg, int nvs_msglen, uintptr_t sndc,
-- 
2.34.1



[PATCH 0/6] Support VMBUS channels without monitoring enabled

2025-02-27 Thread longli
From: Long Li 

Hyperv may expose VMBUS channels without monitoring enabled. In this case,
it programs almost all the data traffic to VF.

This patchset enabled vmbus/netvsc to use channels without monitoring
enabled.

Long Li (6):
  net/netvsc: introduce private data for storing vmbus device for
secondary process
  net/netvsc: introduce get_vmbus_device to get the vmbus device
  bus/vmbus: store UIO fd for secondary process
  bus/vmbus: support channels without monitoring enabled
  bus/vmbus: add rte_vmbus_device to all functions accessing vmbus
  bus/vmbus: set event for channel without monitoring support

 drivers/bus/vmbus/linux/vmbus_bus.c  |  9 +++--
 drivers/bus/vmbus/linux/vmbus_uio.c  |  6 ++--
 drivers/bus/vmbus/private.h  |  2 +-
 drivers/bus/vmbus/rte_bus_vmbus.h| 16 ++---
 drivers/bus/vmbus/vmbus_channel.c| 52 
 drivers/bus/vmbus/vmbus_common_uio.c |  9 +++--
 drivers/net/netvsc/hn_ethdev.c   | 44 ++-
 drivers/net/netvsc/hn_nvs.c  | 33 +-
 drivers/net/netvsc/hn_nvs.h  | 21 +++
 drivers/net/netvsc/hn_rndis.c| 11 +++---
 drivers/net/netvsc/hn_rxtx.c | 16 -
 11 files changed, 152 insertions(+), 67 deletions(-)

-- 
2.34.1



MPLS Push action

2025-02-27 Thread Kishore Padmanabha
Hi,



When MPLS push action is used, using testpmd action  of_push_mpls, it
accepts the ethertype only. How do I specify the MPLS label and other
fields for the MPLS header to be added ? In the doc
,
in section 7.2.3.7 there is mention of OFXPMT_OFB_MPLS_LABEL and other MPLS
fields, but I could not find that in dpdk implementation.



Thanks,

Kishore

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature


[v8 1/5] vhost: skip crypto op fetch before vring init

2025-02-27 Thread Gowrishankar Muthukrishnan
Until virtio avail ring is initialized (by VHOST_USER_SET_VRING_ADDR),
worker thread should not try to fetch crypto op, which would lead to
memory fault.

Fixes: 939066d96563 ("vhost/crypto: add public function implementation")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
v8:
 - fix CI issue.
---
 lib/vhost/vhost_crypto.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index 3dc41a3bd5..a805d29a0e 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include "iotlb.h"
 #include "rte_vhost_crypto.h"
 #include "vhost.h"
 #include "vhost_user.h"
@@ -1580,6 +1581,20 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
 
vq = dev->virtqueue[qid];
 
+   if (unlikely(vq == NULL)) {
+   VC_LOG_ERR("Invalid virtqueue %u", qid);
+   return 0;
+   }
+
+   if (unlikely(rte_rwlock_read_trylock(&vq->access_lock) != 0))
+   return 0;
+
+   vhost_user_iotlb_rd_lock(vq);
+   if (unlikely(!vq->access_ok)) {
+   VC_LOG_DBG("Virtqueue %u vrings not yet initialized", qid);
+   goto out_unlock;
+   }
+
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
start_idx = vq->last_used_idx;
count = avail_idx - start_idx;
@@ -1587,7 +1602,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
count = RTE_MIN(count, nb_ops);
 
if (unlikely(count == 0))
-   return 0;
+   goto out_unlock;
 
/* for zero copy, we need 2 empty mbufs for src and dst, otherwise
 * we need only 1 mbuf as src and dst
@@ -1597,7 +1612,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
if (unlikely(rte_mempool_get_bulk(vcrypto->mbuf_pool,
(void **)mbufs, count * 2) < 0)) {
VC_LOG_ERR("Insufficient memory");
-   return 0;
+   goto out_unlock;
}
 
for (i = 0; i < count; i++) {
@@ -1627,7 +1642,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
if (unlikely(rte_mempool_get_bulk(vcrypto->mbuf_pool,
(void **)mbufs, count) < 0)) {
VC_LOG_ERR("Insufficient memory");
-   return 0;
+   goto out_unlock;
}
 
for (i = 0; i < count; i++) {
@@ -1656,6 +1671,10 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
 
vq->last_used_idx += i;
 
+out_unlock:
+   vhost_user_iotlb_rd_unlock(vq);
+   rte_rwlock_read_unlock(&vq->access_lock);
+
return i;
 }
 
-- 
2.25.1



RE: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

2025-02-27 Thread Gowrishankar Muthukrishnan
> >
> > Ha, and also you should be able to remove:
> > __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */ in
> > vhost_crypto_process_one_req() once implemented.
> >
> 
Removing it would break compilation for thread safety flag.
http://mails.dpdk.org/archives/test-report/2025-February/857515.html

It is due to local vc_req that is passed to func that requires iotlb lock
In vc_req->vq. Even though vc_req->vq is locked vq, GCC does not allow it, as I 
understand.

vc_req = &data_req;
vc_req->desc_idx = desc_idx;
vc_req->dev = vcrypto->dev;
vc_req->vq = vq;

Thanks,
Gowrishankar


[PATCH 3/6] bus/vmbus: store UIO fd for secondary process

2025-02-27 Thread longli
From: Long Li 

Secondary process will get access to vmbus device and this UIO fd for
signaling hyperv host on channels without monitoring support.

Signed-off-by: Long Li 
---
 drivers/bus/vmbus/vmbus_common_uio.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/bus/vmbus/vmbus_common_uio.c 
b/drivers/bus/vmbus/vmbus_common_uio.c
index 4d4613513c..d55aee6537 100644
--- a/drivers/bus/vmbus/vmbus_common_uio.c
+++ b/drivers/bus/vmbus/vmbus_common_uio.c
@@ -86,8 +86,11 @@ vmbus_uio_map_secondary(struct rte_vmbus_device *dev)
return -1;
}
 
-   /* fd is not needed in secondary process, close it */
-   close(fd);
+   if (rte_intr_fd_set(dev->intr_handle, fd))
+   return -1;
+
+   if (rte_intr_type_set(dev->intr_handle, RTE_INTR_HANDLE_UIO_INTX))
+   return -1;
 
/* Create and map primary channel */
if (vmbus_chan_create(dev, dev->relid, 0,
@@ -256,7 +259,7 @@ vmbus_uio_unmap_resource(struct rte_vmbus_device *dev)
/* free uio resource */
rte_free(uio_res);
 
-   /* close fd if in primary process */
+   /* close fd */
if (rte_intr_fd_get(dev->intr_handle) >= 0)
close(rte_intr_fd_get(dev->intr_handle));
 
-- 
2.34.1



[PATCH 5/6] bus/vmbus: add rte_vmbus_device to all functions accessing vmbus

2025-02-27 Thread longli
From: Long Li 

The secondary process can access its vmbus device through device private
region. Add and pass it on all call chains leading to vmbus code.

Signed-off-by: Long Li 
---
 drivers/bus/vmbus/linux/vmbus_uio.c |  2 +-
 drivers/bus/vmbus/private.h |  2 +-
 drivers/bus/vmbus/rte_bus_vmbus.h   | 16 ++-
 drivers/bus/vmbus/vmbus_channel.c   | 32 +
 drivers/net/netvsc/hn_nvs.c | 18 
 drivers/net/netvsc/hn_nvs.h | 15 +++---
 drivers/net/netvsc/hn_rndis.c   | 11 +-
 drivers/net/netvsc/hn_rxtx.c| 16 +++
 8 files changed, 63 insertions(+), 49 deletions(-)

diff --git a/drivers/bus/vmbus/linux/vmbus_uio.c 
b/drivers/bus/vmbus/linux/vmbus_uio.c
index 33edc151f6..8edec869ac 100644
--- a/drivers/bus/vmbus/linux/vmbus_uio.c
+++ b/drivers/bus/vmbus/linux/vmbus_uio.c
@@ -27,7 +27,7 @@
 static void *vmbus_map_addr;
 
 /* Control interrupts */
-void vmbus_uio_irq_control(struct rte_vmbus_device *dev, int32_t onoff)
+void vmbus_uio_irq_control(const struct rte_vmbus_device *dev, int32_t onoff)
 {
if ((rte_intr_fd_get(dev->intr_handle) < 0) ||
write(rte_intr_fd_get(dev->intr_handle), &onoff,
diff --git a/drivers/bus/vmbus/private.h b/drivers/bus/vmbus/private.h
index e33424675c..b67d7cbbf0 100644
--- a/drivers/bus/vmbus/private.h
+++ b/drivers/bus/vmbus/private.h
@@ -110,7 +110,7 @@ void vmbus_insert_device(struct rte_vmbus_device 
*exist_vmbus_dev,
 struct rte_vmbus_device *new_vmbus_dev);
 void vmbus_remove_device(struct rte_vmbus_device *vmbus_device);
 
-void vmbus_uio_irq_control(struct rte_vmbus_device *dev, int32_t onoff);
+void vmbus_uio_irq_control(const struct rte_vmbus_device *dev, int32_t onoff);
 int vmbus_uio_irq_read(struct rte_vmbus_device *dev);
 
 int vmbus_uio_map_resource(struct rte_vmbus_device *dev);
diff --git a/drivers/bus/vmbus/rte_bus_vmbus.h 
b/drivers/bus/vmbus/rte_bus_vmbus.h
index 9467bd8f3d..5636be1a06 100644
--- a/drivers/bus/vmbus/rte_bus_vmbus.h
+++ b/drivers/bus/vmbus/rte_bus_vmbus.h
@@ -176,7 +176,8 @@ bool rte_vmbus_chan_rx_empty(const struct vmbus_channel 
*channel);
  *
  * Sends data in buffer directly to hyper-v via the vmbus
  */
-int rte_vmbus_chan_send(struct vmbus_channel *channel, uint16_t type,
+int rte_vmbus_chan_send(struct rte_vmbus_device *dev,
+   struct vmbus_channel *channel, uint16_t type,
void *data, uint32_t dlen,
uint64_t xact, uint32_t flags, bool *need_sig);
 
@@ -189,7 +190,8 @@ int rte_vmbus_chan_send(struct vmbus_channel *channel, 
uint16_t type,
  * Used when batching multiple sends and only signaling host
  * after the last send.
  */
-void rte_vmbus_chan_signal_tx(const struct vmbus_channel *channel);
+void rte_vmbus_chan_signal_tx(struct rte_vmbus_device *dev,
+ const struct vmbus_channel *channel);
 
 /* Structure for scatter/gather I/O */
 struct iova_list {
@@ -223,7 +225,8 @@ struct iova_list {
  *
  * Sends data in buffer directly to hyper-v via the vmbus
  */
-int rte_vmbus_chan_send_sglist(struct vmbus_channel *channel,
+int rte_vmbus_chan_send_sglist(struct rte_vmbus_device *dev,
+  struct vmbus_channel *channel,
   struct vmbus_gpa gpa[], uint32_t gpacnt,
   void *data, uint32_t dlen,
   uint64_t xact, bool *need_sig);
@@ -243,7 +246,8 @@ int rte_vmbus_chan_send_sglist(struct vmbus_channel 
*channel,
  *   On success, returns 0
  *   On failure, returns negative errno.
  */
-int rte_vmbus_chan_recv(struct vmbus_channel *chan,
+int rte_vmbus_chan_recv(struct rte_vmbus_device *dev,
+   struct vmbus_channel *chan,
void *data, uint32_t *len,
uint64_t *request_id);
 
@@ -273,7 +277,9 @@ int rte_vmbus_chan_recv_raw(struct vmbus_channel *chan,
  * @param bytes_read
  * Number of bytes read since last signal
  */
-void rte_vmbus_chan_signal_read(struct vmbus_channel *chan, uint32_t 
bytes_read);
+void rte_vmbus_chan_signal_read(struct rte_vmbus_device *dev,
+   struct vmbus_channel *chan,
+   uint32_t bytes_read);
 
 /**
  * Determine sub channel index of the given channel
diff --git a/drivers/bus/vmbus/vmbus_channel.c 
b/drivers/bus/vmbus/vmbus_channel.c
index d4b5ba1979..bccef168d3 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -39,7 +39,8 @@ vmbus_set_monitor(const struct vmbus_channel *channel, 
uint32_t monitor_id)
 }
 
 static void
-vmbus_set_event(const struct vmbus_channel *chan)
+vmbus_set_event(struct rte_vmbus_device *dev __rte_unused,
+   const struct vmbus_channel *chan)
 {
vmbus_set_monitor(chan, chan->monitor_id);
 }
@@ -80,7 +81,7 @@ rte_vmbus_set_latency(const struct rte_vmbus_dev

[PATCH 6/6] bus/vmbus: set event for channel without monitoring support

2025-02-27 Thread longli
From: Long Li 

For vmbus channels without monitoring support, use kernel UIO interface
to indicate packet through interrupt page and UIO file handle.

Signed-off-by: Long Li 
---
 drivers/bus/vmbus/vmbus_channel.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/bus/vmbus/vmbus_channel.c 
b/drivers/bus/vmbus/vmbus_channel.c
index bccef168d3..1b54961cff 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -24,6 +24,19 @@ vmbus_sync_set_bit(volatile RTE_ATOMIC(uint32_t) *addr, 
uint32_t mask)
rte_atomic_fetch_or_explicit(addr, mask, rte_memory_order_seq_cst);
 }
 
+static inline void
+vmbus_send_interrupt(const struct rte_vmbus_device *dev, uint32_t relid)
+{
+   uint32_t *int_addr;
+   uint32_t int_mask;
+
+   int_addr = dev->int_page + relid / 32;
+   int_mask = 1u << (relid % 32);
+   vmbus_sync_set_bit(int_addr, int_mask);
+
+   vmbus_uio_irq_control(dev, 1);
+}
+
 static inline void
 vmbus_set_monitor(const struct vmbus_channel *channel, uint32_t monitor_id)
 {
@@ -39,10 +52,12 @@ vmbus_set_monitor(const struct vmbus_channel *channel, 
uint32_t monitor_id)
 }
 
 static void
-vmbus_set_event(struct rte_vmbus_device *dev __rte_unused,
-   const struct vmbus_channel *chan)
+vmbus_set_event(struct rte_vmbus_device *dev, const struct vmbus_channel *chan)
 {
-   vmbus_set_monitor(chan, chan->monitor_id);
+   if (chan->monitor_id != UINT8_MAX)
+   vmbus_set_monitor(chan, chan->monitor_id);
+   else
+   vmbus_send_interrupt(dev, chan->relid);
 }
 
 /*
-- 
2.34.1



[PATCH 1/6] net/netvsc: introduce private data for storing vmbus device for secondary process

2025-02-27 Thread longli
From: Long Li 

To prepare for supporting to set hyperv event from secondary process
when the channel has monitoring disable, introduce a private data
region for storing the vmbus device. The secondary process will get
access to its vmbus device in case it needs to signal the host.

Signed-off-by: Long Li 
---
 drivers/net/netvsc/hn_ethdev.c | 44 +++---
 drivers/net/netvsc/hn_nvs.h|  4 
 2 files changed, 39 insertions(+), 9 deletions(-)

diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index f8cb05a118..4b7b557b5c 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -1423,7 +1423,8 @@ static int eth_hn_probe(struct rte_vmbus_driver *drv 
__rte_unused,
struct rte_vmbus_device *dev)
 {
struct rte_eth_dev *eth_dev;
-   int ret;
+   struct hn_nvs_process_priv *process_priv;
+   int ret = 0;
 
PMD_INIT_FUNC_TRACE();
 
@@ -1434,16 +1435,37 @@ static int eth_hn_probe(struct rte_vmbus_driver *drv 
__rte_unused,
}
 
eth_dev = eth_dev_vmbus_allocate(dev, sizeof(struct hn_data));
-   if (!eth_dev)
-   return -ENOMEM;
+   if (!eth_dev) {
+   ret = -ENOMEM;
+   goto vmbus_alloc_failed;
+   }
 
-   ret = eth_hn_dev_init(eth_dev);
-   if (ret) {
-   eth_dev_vmbus_release(eth_dev);
-   rte_dev_event_monitor_stop();
-   } else {
-   rte_eth_dev_probing_finish(eth_dev);
+   process_priv = rte_zmalloc_socket("netvsc_proc_priv",
+ sizeof(struct hn_nvs_process_priv),
+ RTE_CACHE_LINE_SIZE,
+ dev->device.numa_node);
+   if (!process_priv) {
+   ret = -ENOMEM;
+   goto priv_alloc_failed;
}
+   process_priv->vmbus_dev = dev;
+   eth_dev->process_private = process_priv;
+
+   ret = eth_hn_dev_init(eth_dev);
+   if (ret)
+   goto dev_init_failed;
+
+   rte_eth_dev_probing_finish(eth_dev);
+   return ret;
+
+dev_init_failed:
+   rte_free(process_priv);
+
+priv_alloc_failed:
+   eth_dev_vmbus_release(eth_dev);
+
+vmbus_alloc_failed:
+   rte_dev_event_monitor_stop();
 
return ret;
 }
@@ -1451,6 +1473,7 @@ static int eth_hn_probe(struct rte_vmbus_driver *drv 
__rte_unused,
 static int eth_hn_remove(struct rte_vmbus_device *dev)
 {
struct rte_eth_dev *eth_dev;
+   struct hn_nvs_process_priv *process_priv;
int ret;
 
PMD_INIT_FUNC_TRACE();
@@ -1463,6 +1486,9 @@ static int eth_hn_remove(struct rte_vmbus_device *dev)
if (ret)
return ret;
 
+   process_priv = eth_dev->process_private;
+   rte_free(process_priv);
+
eth_dev_vmbus_release(eth_dev);
rte_dev_event_monitor_stop();
return 0;
diff --git a/drivers/net/netvsc/hn_nvs.h b/drivers/net/netvsc/hn_nvs.h
index 3766d2ee34..88f413f6aa 100644
--- a/drivers/net/netvsc/hn_nvs.h
+++ b/drivers/net/netvsc/hn_nvs.h
@@ -65,6 +65,10 @@
 #define NVS_TYPE_SUBCH_RESP133 /* same as SUBCH_REQ */
 #define NVS_TYPE_TXTBL_NOTE134 /* notification */
 
+/* Private data for primary/secondary processes */
+struct hn_nvs_process_priv {
+   struct rte_vmbus_device *vmbus_dev;
+};
 
 /* NVS message common header */
 struct hn_nvs_hdr {
-- 
2.34.1



[PATCH 4/6] bus/vmbus: support channels without monitoring enabled

2025-02-27 Thread longli
From: Long Li 

Hyperv host may offer channels without monitor enabled. The max monitor
ID it supports is 128. Over those channels without monitor enabled,
Hyperv does not send or receive large amount of data traffic and almost all
the data traffic is going over the VF.

Change the code to not fail on creating channels without monitor enabled.
Use UINT8_MAX (256) to indicate this channel have no monitoring.

Signed-off-by: Long Li 
---
 drivers/bus/vmbus/linux/vmbus_bus.c | 9 ++---
 drivers/bus/vmbus/linux/vmbus_uio.c | 4 ++--
 drivers/bus/vmbus/vmbus_channel.c   | 3 +++
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/bus/vmbus/linux/vmbus_bus.c 
b/drivers/bus/vmbus/linux/vmbus_bus.c
index 01d8111b85..79fd3370b8 100644
--- a/drivers/bus/vmbus/linux/vmbus_bus.c
+++ b/drivers/bus/vmbus/linux/vmbus_bus.c
@@ -280,9 +280,12 @@ vmbus_scan_one(const char *name)
 
/* get monitor id */
snprintf(filename, sizeof(filename), "%s/monitor_id", dirname);
-   if (eal_parse_sysfs_value(filename, &tmp) < 0)
-   goto error;
-   dev->monitor_id = tmp;
+   if (eal_parse_sysfs_value(filename, &tmp) >= 0) {
+   dev->monitor_id = tmp;
+   } else {
+   VMBUS_LOG(NOTICE, "monitor disabled on %s", name);
+   dev->monitor_id = UINT8_MAX;
+   }
 
/* get numa node (if present) */
snprintf(filename, sizeof(filename), "%s/numa_node",
diff --git a/drivers/bus/vmbus/linux/vmbus_uio.c 
b/drivers/bus/vmbus/linux/vmbus_uio.c
index 26edef342d..33edc151f6 100644
--- a/drivers/bus/vmbus/linux/vmbus_uio.c
+++ b/drivers/bus/vmbus/linux/vmbus_uio.c
@@ -451,9 +451,9 @@ int vmbus_uio_get_subchan(struct vmbus_channel *primary,
err = vmbus_uio_sysfs_read(subchan_path, "monitor_id",
   &monid, UINT8_MAX);
if (err) {
-   VMBUS_LOG(NOTICE, "no monitor_id in %s:%s",
+   VMBUS_LOG(NOTICE, "no monitor_id in %s:%s use int mode",
  subchan_path, strerror(-err));
-   goto fail;
+   monid = UINT8_MAX;
}
 
err = vmbus_chan_create(dev, relid, subid, monid, subchan);
diff --git a/drivers/bus/vmbus/vmbus_channel.c 
b/drivers/bus/vmbus/vmbus_channel.c
index 925c2aa081..d4b5ba1979 100644
--- a/drivers/bus/vmbus/vmbus_channel.c
+++ b/drivers/bus/vmbus/vmbus_channel.c
@@ -52,6 +52,9 @@ rte_vmbus_set_latency(const struct rte_vmbus_device *dev,
  const struct vmbus_channel *chan,
  uint32_t latency)
 {
+   if (chan->monitor_id == UINT8_MAX)
+   return;
+
uint32_t trig_idx = chan->monitor_id / VMBUS_MONTRIG_LEN;
uint32_t trig_offs = chan->monitor_id % VMBUS_MONTRIG_LEN;
 
-- 
2.34.1



[v8 2/5] vhost: update vhost_user crypto session parameters

2025-02-27 Thread Gowrishankar Muthukrishnan
As per requirements on vhost_user spec, session id should be
located at the end of session parameter.

Update VhostUserCryptoSessionParam structure to support newer QEMU
versions (v9). Due to additional parameters added in QEMU,
received payload from QEMU would be larger than existing payload.
Hence, it would break parsing vhost_user messages.

This patch addresses both of the above problems.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 lib/vhost/vhost_crypto.c | 12 ++--
 lib/vhost/vhost_user.h   | 33 +
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index a805d29a0e..f9d5128af0 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -238,7 +238,7 @@ struct vhost_crypto_data_req {
 
 static int
 transform_cipher_param(struct rte_crypto_sym_xform *xform,
-   VhostUserCryptoSessionParam *param)
+   VhostUserCryptoSymSessionParam *param)
 {
int ret;
 
@@ -274,7 +274,7 @@ transform_cipher_param(struct rte_crypto_sym_xform *xform,
 
 static int
 transform_chain_param(struct rte_crypto_sym_xform *xforms,
-   VhostUserCryptoSessionParam *param)
+   VhostUserCryptoSymSessionParam *param)
 {
struct rte_crypto_sym_xform *xform_cipher, *xform_auth;
int ret;
@@ -342,10 +342,10 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
struct rte_cryptodev_sym_session *session;
int ret;
 
-   switch (sess_param->op_type) {
+   switch (sess_param->u.sym_sess.op_type) {
case VIRTIO_CRYPTO_SYM_OP_NONE:
case VIRTIO_CRYPTO_SYM_OP_CIPHER:
-   ret = transform_cipher_param(&xform1, sess_param);
+   ret = transform_cipher_param(&xform1, &sess_param->u.sym_sess);
if (unlikely(ret)) {
VC_LOG_ERR("Error transform session msg (%i)", ret);
sess_param->session_id = ret;
@@ -353,7 +353,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
}
break;
case VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING:
-   if (unlikely(sess_param->hash_mode !=
+   if (unlikely(sess_param->u.sym_sess.hash_mode !=
VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH)) {
sess_param->session_id = -VIRTIO_CRYPTO_NOTSUPP;
VC_LOG_ERR("Error transform session message (%i)",
@@ -363,7 +363,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
 
xform1.next = &xform2;
 
-   ret = transform_chain_param(&xform1, sess_param);
+   ret = transform_chain_param(&xform1, &sess_param->u.sym_sess);
if (unlikely(ret)) {
VC_LOG_ERR("Error transform session message (%i)", ret);
sess_param->session_id = ret;
diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index 9a905ee5f4..ef486545ba 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -99,11 +99,10 @@ typedef struct VhostUserLog {
 /* Comply with Cryptodev-Linux */
 #define VHOST_USER_CRYPTO_MAX_HMAC_KEY_LENGTH  512
 #define VHOST_USER_CRYPTO_MAX_CIPHER_KEY_LENGTH64
+#define VHOST_USER_CRYPTO_MAX_KEY_LENGTH   1024
 
 /* Same structure as vhost-user backend session info */
-typedef struct VhostUserCryptoSessionParam {
-   int64_t session_id;
-   uint32_t op_code;
+typedef struct VhostUserCryptoSymSessionParam {
uint32_t cipher_algo;
uint32_t cipher_key_len;
uint32_t hash_algo;
@@ -114,10 +113,36 @@ typedef struct VhostUserCryptoSessionParam {
uint8_t dir;
uint8_t hash_mode;
uint8_t chaining_dir;
-   uint8_t *ciphe_key;
+   uint8_t *cipher_key;
uint8_t *auth_key;
uint8_t cipher_key_buf[VHOST_USER_CRYPTO_MAX_CIPHER_KEY_LENGTH];
uint8_t auth_key_buf[VHOST_USER_CRYPTO_MAX_HMAC_KEY_LENGTH];
+} VhostUserCryptoSymSessionParam;
+
+
+typedef struct VhostUserCryptoAsymRsaParam {
+   uint32_t padding_algo;
+   uint32_t hash_algo;
+} VhostUserCryptoAsymRsaParam;
+
+typedef struct VhostUserCryptoAsymSessionParam {
+   uint32_t algo;
+   uint32_t key_type;
+   uint32_t key_len;
+   uint8_t *key;
+   union {
+   VhostUserCryptoAsymRsaParam rsa;
+   } u;
+   uint8_t key_buf[VHOST_USER_CRYPTO_MAX_KEY_LENGTH];
+} VhostUserCryptoAsymSessionParam;
+
+typedef struct VhostUserCryptoSessionParam {
+   uint32_t op_code;
+   union {
+   VhostUserCryptoSymSessionParam sym_sess;
+   VhostUserCryptoAsymSessionParam asym_sess;
+   } u;
+   int64_t session_id;
 } VhostUserCryptoSessionParam;
 
 typedef struct VhostUserVringArea {
-- 
2.25.1



[v8 0/5] vhost: add RSA support

2025-02-27 Thread Gowrishankar Muthukrishnan
This patch series supports asymmetric RSA in vhost crypto library.
It also includes changes to improve vhost crypto library:
 * support newer QEMU versions.
 * fix broken vhost_crypto example application.
 * stabilize crypto fastpath operations.

Gowrishankar Muthukrishnan (5):
  vhost: skip crypto op fetch before vring init
  vhost: update vhost_user crypto session parameters
  examples/vhost_crypto: fix user callbacks
  vhost: support asymmetric RSA crypto ops
  examples/vhost_crypto: support asymmetric crypto

 doc/guides/rel_notes/release_25_03.rst|   3 +
 doc/guides/sample_app_ug/vhost_crypto.rst |   5 +
 examples/vhost_crypto/main.c  |  54 ++-
 lib/vhost/vhost_crypto.c  | 523 --
 lib/vhost/vhost_user.h|  33 +-
 lib/vhost/virtio_crypto.h |  67 +++
 6 files changed, 623 insertions(+), 62 deletions(-)

-- 
2.25.1



[v8 3/5] examples/vhost_crypto: fix user callbacks

2025-02-27 Thread Gowrishankar Muthukrishnan
In order to handle new vhost user connection, use new_connection
and destroy_connection callbacks.

Fixes: f5188211c721 ("examples/vhost_crypto: add sample application")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 examples/vhost_crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 558c09a60f..b1fe4120b9 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -362,8 +362,8 @@ destroy_device(int vid)
 }
 
 static const struct rte_vhost_device_ops virtio_crypto_device_ops = {
-   .new_device =  new_device,
-   .destroy_device = destroy_device,
+   .new_connection =  new_device,
+   .destroy_connection = destroy_device,
 };
 
 static int
-- 
2.25.1



[PATCH] doc: update ionic driver guides

2025-02-27 Thread Andrew Boyer
Update broken links and add a link for the DSC3-400 product brief.

Cc: sta...@dpdk.org
Signed-off-by: Andrew Boyer 
---
 doc/guides/cryptodevs/ionic.rst | 14 +-
 doc/guides/nics/ionic.rst   | 18 +-
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/doc/guides/cryptodevs/ionic.rst b/doc/guides/cryptodevs/ionic.rst
index 2641835f63..d563602ebe 100644
--- a/doc/guides/cryptodevs/ionic.rst
+++ b/doc/guides/cryptodevs/ionic.rst
@@ -12,11 +12,15 @@ It currently supports the below models:
   `(pdf) 
`__
 - DSC-100 dual-port 100G Distributed Services Card
   `(pdf) 
`__
-- DSC-200 dual-port 200G Distributed Services Card
-  `(pdf) 
`__
-
-Please visit the AMD Pensando web site at
-https://www.amd.com/en/accelerators/pensando for more information.
+- DSC2-200 dual-port 200G Distributed Services Card
+  `(pdf) 
`__
+- DSC3-400 dual-port 400G Distributed Services Card
+  `(pdf) 
`__
+
+Please visit the
+`AMD Pensando Networking
+`_
+web site for more information.
 
 Device Support
 --
diff --git a/doc/guides/nics/ionic.rst b/doc/guides/nics/ionic.rst
index e0eb1b5c9a..a991a2cf3f 100644
--- a/doc/guides/nics/ionic.rst
+++ b/doc/guides/nics/ionic.rst
@@ -7,11 +7,19 @@ IONIC Driver
 The ionic driver provides support for AMD Pensando server adapters.
 It currently supports the below models:
 
-- DSC-25 dual-port 25G Distributed Services Card `(pdf) 
`__
-- DSC-100 dual-port 100G Distributed Services Card `(pdf) 
`__
-- DSC-200 dual-port 200G Distributed Services Card `(pdf) 
`__
-
-Please visit the AMD Pensando web site at 
https://www.amd.com/en/accelerators/pensando for more information.
+- DSC-25 dual-port 25G Distributed Services Card
+  `(pdf) 
`__
+- DSC-100 dual-port 100G Distributed Services Card
+  `(pdf) 
`__
+- DSC2-200 dual-port 200G Distributed Services Card
+  `(pdf) 
`__
+- DSC3-400 dual-port 400G Distributed Services Card
+  `(pdf) 
`__
+
+Please visit the
+`AMD Pensando Networking
+`_
+web site for more information.
 
 Identifying the Adapter
 ---
-- 
2.17.1



Re: [PATCH] app/test: fix DMA API tests in IOVA as PA mode

2025-02-27 Thread fengchengwen
Reviewed-by: Chengwen Feng 

On 2025/2/27 21:27, Bruce Richardson wrote:
> When running without IOMMU for address translation, i.e. IOVAs are
> physical rather than virtual addresses, we need to translate the
> pointers to IOVAs for the completion API tests.
> 
> Fixes: 9942ebb9c698 ("test/dma: add dmadev API test")
> Cc: fengcheng...@huawei.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Bruce Richardson 



Re: release candidate 25.03-rc1

2025-02-27 Thread Thinh Tran

IBM - Power Systems
DPDK v25.03-rc1

* Build CI on Fedora 38,39,40 and 41 container images for ppc64le
* Basic PF on Mellanox: No issue found
* Performance: not tested.
* OS: - RHEL 9.4  kernel: 5.14.0-427.40.1.el9_4.ppc64le
with gcc version 11.4.1 20231218 (Red Hat 11.4.1-3) (GCC)
  - SLES15 SP5  kernel: 5.14.21-150500.55.49-default
with gcc version 13.2.1 20230912 (SUSE Linux)
  - SLES 15-SP6 kernel: 6.4.0-150600.21-default
with gcc version 13.2.1 20240206 (SUSE Linux)


Systems tested:
 - LPARs on IBM Power10 CHRP IBM,9105-22A
NICs:
- Mellanox Technologies MT28800 Family [ConnectX-5 Ex]
- firmware version: 16.35.4030
- OFED-internal-25.01-0.6.0

Regards,
Thinh Tran

On 2/12/2025 10:49 AM, Thomas Monjalon wrote:

A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v25.03-rc1

There are 478 new patches in this snapshot.

Release notes:
https://doc.dpdk.org/guides/rel_notes/release_25_03.html

Highlights of 25.03-rc1:
- Staged-Ordered ring (SORING)
- mbuf raw bulk functions
- some Intel drivers merged together
- Yunsilicon xsc networking driver
- ZTE Storage Data Accelerator (ZSDA) driver
- Intel compiler icc support replaced by icx
- more function annotations for analyzers
- more MSVC compatibility

Please test and report issues on bugs.dpdk.org.

DPDK 25.03-rc2 is expected in more than two weeks (end of February).

Thank you everyone






Re: [PATCH] mempool: micro optimizations

2025-02-27 Thread Bruce Richardson
On Thu, Feb 27, 2025 at 10:14:27AM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Sent: Wednesday, 26 February 2025 17.53
> > 
> > On Wed, Feb 26, 2025 at 03:59:22PM +, Morten Brørup wrote:
> > > The comparisons lcore_id < RTE_MAX_LCORE and lcore_id != LCORE_ID_ANY
> > are
> > > equivalent, but the latter compiles to fewer bytes of code space.
> > > Similarly for lcore_id >= RTE_MAX_LCORE and lcore_id == LCORE_ID_ANY.
> > >
> > > The rte_mempool_get_ops() function is also used in the fast path, so
> > > RTE_VERIFY() was replaced by RTE_ASSERT().
> > >
> > > Compilers implicitly consider comparisons of variable == 0 likely, so
> > > unlikely() was added to the check for no mempool cache (mp-
> > >cache_size ==
> > > 0) in the rte_mempool_default_cache() function.
> > >
> > > The rte_mempool_do_generic_put() function for adding objects to a
> > mempool
> > > was refactored as follows:
> > > - The comparison for the request itself being too big, which is
> > considered
> > >   unlikely, was moved down and out of the code path where the cache
> > has
> > >   sufficient room for the added objects, which is considered the most
> > >   likely code path.
> > > - Added __rte_assume() about the cache length, size and threshold,
> > for
> > >   compiler optimization when "n" is compile time constant.
> > > - Added __rte_assume() about "ret" being zero, so other functions
> > using
> > >   the value returned by this function can be potentially optimized by
> > the
> > >   compiler; especially when it merges multiple sequential code paths
> > of
> > >   inlined code depending on the return value being either zero or
> > >   negative.
> > > - The refactored source code (with comments) made the separate
> > comment
> > >   describing the cache flush/add algorithm superfluous, so it was
> > removed.
> > >
> > > A few more likely()/unlikely() were added.
> > >
> > > A few comments were improved for readability.
> > >
> > > Some assertions, RTE_ASSERT(), were added. Most importantly to assert
> > that
> > > the return values of the mempool drivers' enqueue and dequeue
> > operations
> > > are API compliant, i.e. 0 (for success) or negative (for failure),
> > and
> > > never positive.
> > >
> > > Signed-off-by: Morten Brørup 
> > > ---
> > >  lib/mempool/rte_mempool.h | 67 ++---
> > --
> > >  1 file changed, 38 insertions(+), 29 deletions(-)
> > >
> > Is there any measurable performance change with these modifications?
> 
> It varies.
> Here are some of the good ones, tested on a VM under VMware:
> 
> mempool_autotest cache=512 cores=1
> n_get_bulk=64 n_put_bulk=64 n_keep=128 constant_n=0
> rate_persec=1309408130 -> 1417067889 : +8.2 %
> 
> mempool_autotest cache=512 cores=1
> n_get_bulk=64 n_put_bulk=64 n_keep=128 constant_n=1
> rate_persec=1479812844 -> 1573307159 : +6.3 %
> 
> mempool_autotest cache=512 cores=1
> n_max_bulk=32 n_keep=128 constant_n=0
> rate_persec=825183959 -> 868013386 : +5.2 %
> 
> The last result is from a new type of test where the size of every get/put 
> varies between 1 and n_max_bulk, so the CPU's dynamic branch predictor cannot 
> predict the request size.
> I'll probably provide a separate patch for test_mempool_perf.c with this new 
> test type, when I have finished it.
>

Thanks, those results look worthwhile so.

/Bruce 


Re: [v6 1/5] vhost: skip crypto op fetch before vring init

2025-02-27 Thread Maxime Coquelin




On 2/27/25 10:15 AM, Maxime Coquelin wrote:

Hi Gowri,

Thanks for the change, but I think there is an issue with the locking,
more below:

On 2/26/25 7:43 PM, Gowrishankar Muthukrishnan wrote:

Until virtio avail ring is initialized (by VHOST_USER_SET_VRING_ADDR),
worker thread should not try to fetch crypto op, which would lead to
memory fault.

Fixes: 939066d96563 ("vhost/crypto: add public function implementation")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
v6:
  - added lock checks.
---
  lib/vhost/vhost_crypto.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index 3dc41a3bd5..d3d13eff07 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -8,6 +8,7 @@
  #include 
  #include 
+#include "iotlb.h"
  #include "rte_vhost_crypto.h"
  #include "vhost.h"
  #include "vhost_user.h"
@@ -1580,7 +1581,26 @@ rte_vhost_crypto_fetch_requests(int vid, 
uint32_t qid,

  vq = dev->virtqueue[qid];
+    if (unlikely(vq == NULL)) {
+    VC_LOG_ERR("Invalid virtqueue %u", qid);
+    return 0;
+    }
+
+    if (unlikely(rte_rwlock_read_trylock(&vq->access_lock) != 0))
+    return 0;
+
+    vhost_user_iotlb_rd_lock(vq);
+    if (unlikely(!vq->access_ok)) {
+    VC_LOG_DBG("Virtqueue %u vrings not yet initialized", qid);
+    vhost_user_iotlb_rd_unlock(vq);
+    rte_rwlock_read_unlock(&vq->access_lock);
+    return 0;
+    }
+
  avail_idx = *((volatile uint16_t *)&vq->avail->idx);
+    vhost_user_iotlb_rd_unlock(vq);
+    rte_rwlock_read_unlock(&vq->access_lock);
+


You should only unlock at the end of the function, otherwise there is 
not much protection.


Ha, and also you should be able to remove: 
__rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */

in vhost_crypto_process_one_req() once implemented.

Regards,
Maxime



  start_idx = vq->last_used_idx;
  count = avail_idx - start_idx;
  count = RTE_MIN(count, VHOST_CRYPTO_MAX_BURST_SIZE);






RE: [EXTERNAL] Re: [PATCH v2] net/virtio: add virtio hash report feature

2025-02-27 Thread Shiva Shankar Kommula
> -Original Message-
> From: Maxime Coquelin 
> Sent: Tuesday, February 25, 2025 9:39 PM
> To: Shiva Shankar Kommula ; dev@dpdk.org;
> chen...@nvidia.com
> Cc: david.march...@redhat.com; Jerin Jacob ; Nithin
> Kumar Dabilpuram ; Srujana Challa
> 
> Subject: [EXTERNAL] Re: [PATCH v2] net/virtio: add virtio hash report feature
> 
> Hi, On 1/27/25 8: 41 AM, Kommula Shiva Shankar wrote: > This patch adds
> virtio hash report feature, which is > supported in packet queue mode with
> scalar version Why only restrict to packed ring? isn't it also compatible with
> split ring?
> 
> Hi,
> 
> On 1/27/25 8:41 AM, Kommula Shiva Shankar wrote:
> > This patch adds virtio hash report feature, which is supported in
> > packet queue mode with scalar version
> 
> Why only restrict to packed ring? isn't it also compatible with split ring?
Hi Maxim, 
Yes, it is. I can add split ring support later if it's alright
> 
> >
> > Signed-off-by: Kommula Shiva Shankar 
> > ---
> >   drivers/net/virtio/virtio.h   |  2 ++
> >   drivers/net/virtio/virtio_ethdev.c| 20 -
> >   drivers/net/virtio/virtio_ethdev.h|  1 +
> >   drivers/net/virtio/virtio_rxtx.c  | 30 +++
> >   .../net/virtio/virtio_user/virtio_user_dev.c  |  1 +
> >   drivers/net/virtio/virtqueue.h| 21 +
> >   6 files changed, 74 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/virtio/virtio.h b/drivers/net/virtio/virtio.h
> > index ef5827c5f5..c2a0fd477c 100644
> > --- a/drivers/net/virtio/virtio.h
> > +++ b/drivers/net/virtio/virtio.h
> > @@ -30,6 +30,7 @@
> >   #define VIRTIO_NET_F_GUEST_ANNOUNCE 21/* Guest can
> announce device on the network */
> >   #define VIRTIO_NET_F_MQ   22  /* Device supports Receive
> Flow Steering */
> >   #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > +#define VIRTIO_NET_F_HASH_REPORT  57/* Supports hash report */
> >   #define VIRTIO_NET_F_RSS  60  /* RSS supported */
> >
> >   /*
> > @@ -187,6 +188,7 @@ struct virtio_hw {
> > uint8_t started;
> > uint8_t weak_barriers;
> > uint8_t vlan_strip;
> > +   uint8_t has_hash_report;
> > bool rx_ol_scatter;
> > uint8_t has_tx_offload;
> > uint8_t has_rx_offload;
> > diff --git a/drivers/net/virtio/virtio_ethdev.c
> > b/drivers/net/virtio/virtio_ethdev.c
> > index 70d4839def..caacbce57a 100644
> > --- a/drivers/net/virtio/virtio_ethdev.c
> > +++ b/drivers/net/virtio/virtio_ethdev.c
> > @@ -1796,7 +1796,9 @@ virtio_init_device(struct rte_eth_dev *eth_dev,
> uint64_t req_features)
> > eth_dev->data->dev_flags &= ~RTE_ETH_DEV_INTR_LSC;
> >
> > /* Setting up rx_header size for the device */
> > -   if (virtio_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF) ||
> > +   if (virtio_with_feature(hw, VIRTIO_NET_F_HASH_REPORT))
> > +   hw->vtnet_hdr_size = sizeof(struct
> virtio_net_hdr_hash_report);
> > +   else if (virtio_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF) ||
> > virtio_with_feature(hw, VIRTIO_F_VERSION_1) ||
> > virtio_with_packed_queue(hw))
> > hw->vtnet_hdr_size = sizeof(struct
> virtio_net_hdr_mrg_rxbuf); @@
> > -2181,6 +2183,10 @@ virtio_dev_configure(struct rte_eth_dev *dev)
> > (1ULL << VIRTIO_NET_F_GUEST_TSO4) |
> > (1ULL << VIRTIO_NET_F_GUEST_TSO6);
> >
> > +   if (rx_offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH)
> > +   req_features |=
> > +   (1ULL << VIRTIO_NET_F_HASH_REPORT);
> > +
> > if (tx_offloads & (RTE_ETH_TX_OFFLOAD_UDP_CKSUM |
> >RTE_ETH_TX_OFFLOAD_TCP_CKSUM))
> > req_features |= (1ULL << VIRTIO_NET_F_CSUM); @@ -2233,6
> +2239,9 @@
> > virtio_dev_configure(struct rte_eth_dev *dev)
> > if (rx_offloads & RTE_ETH_RX_OFFLOAD_VLAN_STRIP)
> > hw->vlan_strip = 1;
> >
> > +   if (rx_offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH)
> > +   hw->has_hash_report = 1;
> > +
> > hw->rx_ol_scatter = (rx_offloads & RTE_ETH_RX_OFFLOAD_SCATTER);
> >
> > if ((rx_offloads & RTE_ETH_RX_OFFLOAD_VLAN_FILTER) && @@ -
> 2285,6
> > +2294,12 @@ virtio_dev_configure(struct rte_eth_dev *dev)
> > "disabled packed ring vectorized rx for
> TCP_LRO enabled");
> > hw->use_vec_rx = 0;
> > }
> > +
> > +   if (rx_offloads & RTE_ETH_RX_OFFLOAD_RSS_HASH) {
> > +   PMD_DRV_LOG(INFO,
> > +   "disabled packed ring vectorized rx for
> RSS_HASH enabled");
> > +   hw->use_vec_rx = 0;
> > +   }
> > }
> > } else {
> > if (virtio_with_feature(hw, VIRTIO_F_IN_ORDER)) { @@ -
> 2669,6
> > +2684,9 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *dev_info)
> > dev_info->flow_type_rss_offloads = 0;
> > }
> >
> > +   if (hos

[PATCH] net/mlx5: fix assert failure on hairpin queue release

2025-02-27 Thread Maayan Kashani
Assert was triggered because of ctrl_ref mismatch on hairpin queue.
Fixed the mismatch.

Fixes: 09c2555 ("net/mlx5: support shared Rx queue")
Cc: sta...@dpdk.org

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5.h  |  1 +
 drivers/net/mlx5/mlx5_flow.c |  4 ++--
 drivers/net/mlx5/mlx5_rx.h   |  1 +
 drivers/net/mlx5/mlx5_rxq.c  | 12 
 4 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 545ba48b3cd..6df99c25e2f 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -2023,6 +2023,7 @@ struct mlx5_priv {
uint32_t ctrl_flows; /* Control flow rules. */
rte_spinlock_t flow_list_lock;
struct mlx5_obj_ops obj_ops; /* HW objects operations. */
+   LIST_HEAD(rxq, mlx5_rxq_ctrl) rxqsctrl; /* DPDK Rx queues. */
LIST_HEAD(rxqobj, mlx5_rxq_obj) rxqsobj; /* Verbs/DevX Rx queues. */
struct mlx5_list *hrxqs; /* Hash Rx queues. */
LIST_HEAD(txq, mlx5_txq_ctrl) txqsctrl; /* DPDK Tx queues. */
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index f8b3e504b35..6169ebc13f6 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -1648,13 +1648,13 @@ flow_rxq_mark_flag_set(struct rte_eth_dev *dev)
opriv->domain_id != priv->domain_id ||
opriv->mark_enabled)
continue;
-   LIST_FOREACH(rxq_ctrl, &opriv->sh->shared_rxqs, 
share_entry) {
+   LIST_FOREACH(rxq_ctrl, &opriv->rxqsctrl, next) {
rxq_ctrl->rxq.mark = 1;
}
opriv->mark_enabled = 1;
}
} else {
-   LIST_FOREACH(rxq_ctrl, &priv->sh->shared_rxqs, share_entry) {
+   LIST_FOREACH(rxq_ctrl, &priv->rxqsctrl, next) {
rxq_ctrl->rxq.mark = 1;
}
priv->mark_enabled = 1;
diff --git a/drivers/net/mlx5/mlx5_rx.h b/drivers/net/mlx5/mlx5_rx.h
index f80a2e32279..6380895502e 100644
--- a/drivers/net/mlx5/mlx5_rx.h
+++ b/drivers/net/mlx5/mlx5_rx.h
@@ -169,6 +169,7 @@ struct __rte_cache_aligned mlx5_rxq_data {
 /* RX queue control descriptor. */
 struct mlx5_rxq_ctrl {
struct mlx5_rxq_data rxq; /* Data path structure. */
+   LIST_ENTRY(mlx5_rxq_ctrl) next; /* Pointer to the next element. */
LIST_HEAD(priv, mlx5_rxq_priv) owners; /* Owner rxq list. */
struct mlx5_rxq_obj *obj; /* Verbs/DevX elements. */
struct mlx5_dev_ctx_shared *sh; /* Shared context. */
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index a5971b5cdda..5cf7d4971b3 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -1037,6 +1037,7 @@ mlx5_rx_hairpin_queue_setup(struct rte_eth_dev *dev, 
uint16_t idx,
rte_errno = ENOMEM;
return -rte_errno;
}
+   rte_atomic_fetch_add_explicit(&rxq_ctrl->ctrl_ref, 1, 
rte_memory_order_relaxed);
DRV_LOG(DEBUG, "port %u adding hairpin Rx queue %u to list",
dev->data->port_id, idx);
dev->data->rx_queues[idx] = &rxq_ctrl->rxq;
@@ -2006,8 +2007,9 @@ mlx5_rxq_new(struct rte_eth_dev *dev, uint16_t idx, 
uint16_t desc,
tmpl->rxq.shared = 1;
tmpl->share_group = conf->share_group;
tmpl->share_qid = conf->share_qid;
+   LIST_INSERT_HEAD(&priv->sh->shared_rxqs, tmpl, share_entry);
}
-   LIST_INSERT_HEAD(&priv->sh->shared_rxqs, tmpl, share_entry);
+   LIST_INSERT_HEAD(&priv->rxqsctrl, tmpl, next);
rte_atomic_store_explicit(&tmpl->ctrl_ref, 1, rte_memory_order_relaxed);
return tmpl;
 error:
@@ -2061,7 +2063,7 @@ mlx5_rxq_hairpin_new(struct rte_eth_dev *dev, struct 
mlx5_rxq_priv *rxq,
tmpl->rxq.idx = idx;
rxq->hairpin_conf = *hairpin_conf;
mlx5_rxq_ref(dev, idx);
-   LIST_INSERT_HEAD(&priv->sh->shared_rxqs, tmpl, share_entry);
+   LIST_INSERT_HEAD(&priv->rxqsctrl, tmpl, next);
rte_atomic_store_explicit(&tmpl->ctrl_ref, 1, rte_memory_order_relaxed);
return tmpl;
 }
@@ -2336,7 +2338,9 @@ mlx5_rxq_release(struct rte_eth_dev *dev, uint16_t idx)
if (!rxq_ctrl->is_hairpin)
mlx5_mr_btree_free
(&rxq_ctrl->rxq.mr_ctrl.cache_bh);
-   LIST_REMOVE(rxq_ctrl, share_entry);
+   if (rxq_ctrl->rxq.shared)
+   LIST_REMOVE(rxq_ctrl, share_entry);
+   LIST_REMOVE(rxq_ctrl, next);
mlx5_free(rxq_ctrl);
}
dev->data->rx_queues[idx] = NULL;
@@ -2362,7 +2366,7 @@ mlx5_rxq_verify(struct rte_eth_dev *dev)
struct mlx5_rxq_ctrl *rxq_ctrl;
int ret = 0;
 
-   

[PATCH] net/mlx5: fix LACP packets handling in isolated mode

2025-02-27 Thread Maayan Kashani
In HWS(dv_flow_en=2) mode, in the routine that enables traffic,  isolated
mode check was before LACP default rules creation as opposed to
legacy mode handling.

As a result, the LACP default rules were not created in HWS mode
and LACP packets arrived to testpmd.
The fix was to create the LACP default rules in isolated mode.

Fixes: 87e4384d2662 ("net/mlx5: fix condition of LACP miss flow")
Cc: sta...@dpdk.org

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_trigger.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_trigger.c b/drivers/net/mlx5/mlx5_trigger.c
index 79b3d4d9821..4ee44e91658 100644
--- a/drivers/net/mlx5/mlx5_trigger.c
+++ b/drivers/net/mlx5/mlx5_trigger.c
@@ -1533,11 +1533,11 @@ mlx5_traffic_enable_hws(struct rte_eth_dev *dev)
} else {
DRV_LOG(INFO, "port %u FDB default rule is disabled", 
dev->data->port_id);
}
-   if (priv->isolated)
-   return 0;
if (!priv->sh->config.lacp_by_user && priv->pf_bond >= 0 && 
priv->master)
if (mlx5_flow_hw_lacp_rx_flow(dev))
goto error;
+   if (priv->isolated)
+   return 0;
if (dev->data->promiscuous)
flags |= MLX5_CTRL_PROMISCUOUS;
if (dev->data->all_multicast)
-- 
2.21.0



RE: [PATCH v3 2/3] eal: only use numbers as align parameters for MSVC

2025-02-27 Thread Konstantin Ananyev



> 
> After the instruction set updates for MSVC the error below popped up:
> 
> ..\lib\eal\x86\include\rte_vect.h(82): error C2059: syntax error: '('
> 
> The issue is that MSVC does not allow __rte_aligned(RTE_X86_ZMM_SIZE).
> It only accepts numbers that are power of 2. So, even though
> RTE_X86_ZMM_SIZE represents a number that is a power of two it cannot
> be used directly.
> https://learn.microsoft.com/en-us/cpp/cpp/align-cpp?view=msvc-170
> 
> Signed-off-by: Andre Muezerie 
> Acked-by: Bruce Richardson 
> ---
>  lib/eal/x86/include/rte_vect.h | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eal/x86/include/rte_vect.h b/lib/eal/x86/include/rte_vect.h
> index 70c78e9b77..9ea158b27e 100644
> --- a/lib/eal/x86/include/rte_vect.h
> +++ b/lib/eal/x86/include/rte_vect.h
> @@ -76,9 +76,18 @@ __extension__ ({\
> 
>  #ifdef __AVX512F__
> 
> -#define RTE_X86_ZMM_SIZE (sizeof(__m512i))
> +#define RTE_X86_ZMM_SIZE64
>  #define RTE_X86_ZMM_MASK (RTE_X86_ZMM_SIZE - 1)
> 
> +/*
> + * MSVC does not allow __rte_aligned(sizeof(__m512i)). It only accepts
> + * numbers that are power of 2. So, even though sizeof(__m512i) represents a
> + * number that is a power of two it cannot be used directly.
> + * Ref: https://learn.microsoft.com/en-us/cpp/cpp/align-cpp?view=msvc-170
> + * The static assert below ensures that the hardcoded value defined as
> + * RTE_X86_ZMM_SIZE is equal to sizeof(__m512i).
> + */
> +static_assert(RTE_X86_ZMM_SIZE == (sizeof(__m512i)), "Unexpected size of 
> __m512i");
>  typedef union __rte_aligned(RTE_X86_ZMM_SIZE) __rte_x86_zmm {
>   __m512i  z;
>   ymm_ty[RTE_X86_ZMM_SIZE / sizeof(ymm_t)];
> --

Acked-by: Konstantin Ananyev 

> 2.48.1.vfs.0.0



RE: [PATCH] mempool: micro optimizations

2025-02-27 Thread Morten Brørup
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> Sent: Wednesday, 26 February 2025 17.53
> 
> On Wed, Feb 26, 2025 at 03:59:22PM +, Morten Brørup wrote:
> > The comparisons lcore_id < RTE_MAX_LCORE and lcore_id != LCORE_ID_ANY
> are
> > equivalent, but the latter compiles to fewer bytes of code space.
> > Similarly for lcore_id >= RTE_MAX_LCORE and lcore_id == LCORE_ID_ANY.
> >
> > The rte_mempool_get_ops() function is also used in the fast path, so
> > RTE_VERIFY() was replaced by RTE_ASSERT().
> >
> > Compilers implicitly consider comparisons of variable == 0 likely, so
> > unlikely() was added to the check for no mempool cache (mp-
> >cache_size ==
> > 0) in the rte_mempool_default_cache() function.
> >
> > The rte_mempool_do_generic_put() function for adding objects to a
> mempool
> > was refactored as follows:
> > - The comparison for the request itself being too big, which is
> considered
> >   unlikely, was moved down and out of the code path where the cache
> has
> >   sufficient room for the added objects, which is considered the most
> >   likely code path.
> > - Added __rte_assume() about the cache length, size and threshold,
> for
> >   compiler optimization when "n" is compile time constant.
> > - Added __rte_assume() about "ret" being zero, so other functions
> using
> >   the value returned by this function can be potentially optimized by
> the
> >   compiler; especially when it merges multiple sequential code paths
> of
> >   inlined code depending on the return value being either zero or
> >   negative.
> > - The refactored source code (with comments) made the separate
> comment
> >   describing the cache flush/add algorithm superfluous, so it was
> removed.
> >
> > A few more likely()/unlikely() were added.
> >
> > A few comments were improved for readability.
> >
> > Some assertions, RTE_ASSERT(), were added. Most importantly to assert
> that
> > the return values of the mempool drivers' enqueue and dequeue
> operations
> > are API compliant, i.e. 0 (for success) or negative (for failure),
> and
> > never positive.
> >
> > Signed-off-by: Morten Brørup 
> > ---
> >  lib/mempool/rte_mempool.h | 67 ++---
> --
> >  1 file changed, 38 insertions(+), 29 deletions(-)
> >
> Is there any measurable performance change with these modifications?

It varies.
Here are some of the good ones, tested on a VM under VMware:

mempool_autotest cache=512 cores=1
n_get_bulk=64 n_put_bulk=64 n_keep=128 constant_n=0
rate_persec=1309408130 -> 1417067889 : +8.2 %

mempool_autotest cache=512 cores=1
n_get_bulk=64 n_put_bulk=64 n_keep=128 constant_n=1
rate_persec=1479812844 -> 1573307159 : +6.3 %

mempool_autotest cache=512 cores=1
n_max_bulk=32 n_keep=128 constant_n=0
rate_persec=825183959 -> 868013386 : +5.2 %

The last result is from a new type of test where the size of every get/put 
varies between 1 and n_max_bulk, so the CPU's dynamic branch predictor cannot 
predict the request size.
I'll probably provide a separate patch for test_mempool_perf.c with this new 
test type, when I have finished it.



Re: [v6 1/5] vhost: skip crypto op fetch before vring init

2025-02-27 Thread Maxime Coquelin

Hi Gowri,

Thanks for the change, but I think there is an issue with the locking,
more below:

On 2/26/25 7:43 PM, Gowrishankar Muthukrishnan wrote:

Until virtio avail ring is initialized (by VHOST_USER_SET_VRING_ADDR),
worker thread should not try to fetch crypto op, which would lead to
memory fault.

Fixes: 939066d96563 ("vhost/crypto: add public function implementation")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
v6:
  - added lock checks.
---
  lib/vhost/vhost_crypto.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index 3dc41a3bd5..d3d13eff07 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -8,6 +8,7 @@
  #include 
  #include 
  
+#include "iotlb.h"

  #include "rte_vhost_crypto.h"
  #include "vhost.h"
  #include "vhost_user.h"
@@ -1580,7 +1581,26 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
  
  	vq = dev->virtqueue[qid];
  
+	if (unlikely(vq == NULL)) {

+   VC_LOG_ERR("Invalid virtqueue %u", qid);
+   return 0;
+   }
+
+   if (unlikely(rte_rwlock_read_trylock(&vq->access_lock) != 0))
+   return 0;
+
+   vhost_user_iotlb_rd_lock(vq);
+   if (unlikely(!vq->access_ok)) {
+   VC_LOG_DBG("Virtqueue %u vrings not yet initialized", qid);
+   vhost_user_iotlb_rd_unlock(vq);
+   rte_rwlock_read_unlock(&vq->access_lock);
+   return 0;
+   }
+
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
+   vhost_user_iotlb_rd_unlock(vq);
+   rte_rwlock_read_unlock(&vq->access_lock);
+


You should only unlock at the end of the function, otherwise there is 
not much protection.



start_idx = vq->last_used_idx;
count = avail_idx - start_idx;
count = RTE_MIN(count, VHOST_CRYPTO_MAX_BURST_SIZE);




[PATCH] doc: add limitation under unified FDB

2025-02-27 Thread Maayan Kashani
Add limitation for unified FDB group 0 table creation.

Signed-off-by: Maayan Kashani 
Acked-by: Bing Zhao 
---
 doc/guides/nics/mlx5.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 190c58b54d6..efa4c708d51 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -288,6 +288,12 @@ Limitations
 - RTE_FLOW_ITEM_TYPE_MPLS matching is not supported on group 0.
 - mpls_encap and mpls_decap actions support only one level of MPLS.
 
+  - Template table with flags wire_orig/vport_orig cannot be created
+on group 0 (group 1 in practice), since group 0 is created on startup
+in UNIFIED_FDB domain.
+
+  - rte_flow_action_mark id is not supported in FDB_TX domain.
+
 - When using Verbs flow engine (``dv_flow_en`` = 0), flow pattern without any
   specific VLAN will match for VLAN packets as well:
 
-- 
2.21.0



[PATCH] net/mlx5: fix crash when using represented port w/o port ID

2025-02-27 Thread Maayan Kashani
For non template API on top of HWS, when trying to use
represented-port item w/o setting the ethdev_port_id,
it crashes.

Added default values to match the case for SWS.
Default port is now eswitch manager id.

Fixes: c55c2bf35333 ("net/mlx5/hws: add definer layer")
Cc: sta...@dpdk.org

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 98d670fc1ce..a4b9306d2b8 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -772,10 +772,11 @@ mlx5dr_definer_vport_set(struct mlx5dr_definer_fc *fc,
 uint8_t *tag)
 {
const struct rte_flow_item_ethdev *v = item_spec;
-   const struct flow_hw_port_info *port_info;
+   const struct flow_hw_port_info *port_info = NULL;
uint32_t regc_value;
 
-   port_info = flow_hw_conv_port_id(fc->dr_ctx, v->port_id);
+   if (v)
+   port_info = flow_hw_conv_port_id(fc->dr_ctx, v->port_id);
if (unlikely(!port_info))
regc_value = BAD_PORT;
else
@@ -1585,10 +1586,11 @@ mlx5dr_definer_conv_item_port(struct 
mlx5dr_definer_conv_data *cd,
  int item_idx)
 {
struct mlx5dr_cmd_query_caps *caps = cd->ctx->caps;
-   const struct rte_flow_item_ethdev *m = item->mask;
+   uint16_t port_id = item->mask ?
+  ((const struct rte_flow_item_ethdev 
*)(item->mask))->port_id : 0;
struct mlx5dr_definer_fc *fc;
 
-   if (m->port_id) {
+   if (port_id) {
if (!caps->wire_regc_mask) {
DR_LOG(ERR, "Port ID item not supported, missing wire 
REGC mask");
rte_errno = ENOTSUP;
@@ -1603,10 +1605,6 @@ mlx5dr_definer_conv_item_port(struct 
mlx5dr_definer_conv_data *cd,
fc->bit_off = rte_ctz32(caps->wire_regc_mask);
fc->bit_mask = caps->wire_regc_mask >> fc->bit_off;
fc->dr_ctx = cd->ctx;
-   } else {
-   DR_LOG(ERR, "Pord ID item mask must specify ID mask");
-   rte_errno = EINVAL;
-   return rte_errno;
}
 
return 0;
-- 
2.21.0



[PATCH 1/2] net/mlx5: fix non template set VLAN VID

2025-02-27 Thread Maayan Kashani
Support set vlan vid in non template on top of HWS.
Update relevant return errors in the relevant functions to avoid crash.
Mask the vlan vid action in non template mode
such that the action template create will use the vid value.

Fixes: 00a0a6b80674 ("net/mlx5: support indirect actions in non-template setup")
Cc: sta...@dpdk.org

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index 3bfb2f35c12..ec047e855e3 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -714,6 +714,9 @@ flow_hw_action_flags_get(const struct rte_flow_action 
actions[],
case RTE_FLOW_ACTION_TYPE_OF_POP_VLAN:
action_flags |= MLX5_FLOW_ACTION_OF_POP_VLAN;
break;
+   case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+   action_flags |= MLX5_FLOW_ACTION_OF_SET_VLAN_VID;
+   break;
case RTE_FLOW_ACTION_TYPE_JUMP:
action_flags |= MLX5_FLOW_ACTION_JUMP;
break;
@@ -7811,22 +7814,23 @@ flow_hw_parse_flow_actions_to_dr_actions(struct 
rte_eth_dev *dev,
return -EINVAL;
 }
 
-static void
+static int
 flow_hw_set_vlan_vid(struct rte_eth_dev *dev,
 struct rte_flow_action *ra,
 struct rte_flow_action *rm,
 struct rte_flow_action_modify_field *spec,
 struct rte_flow_action_modify_field *mask,
-int set_vlan_vid_ix)
+int set_vlan_vid_ix,
+struct rte_flow_error *error)
 {
-   struct rte_flow_error error;
const bool masked = rm[set_vlan_vid_ix].conf &&
(((const struct rte_flow_action_of_set_vlan_vid *)
rm[set_vlan_vid_ix].conf)->vlan_vid != 0);
const struct rte_flow_action_of_set_vlan_vid *conf =
ra[set_vlan_vid_ix].conf;
int width = mlx5_flow_item_field_width(dev, RTE_FLOW_FIELD_VLAN_ID, 0,
-  NULL, &error);
+  NULL, error);
+   MLX5_ASSERT(width);
*spec = (typeof(*spec)) {
.operation = RTE_FLOW_MODIFY_SET,
.dst = {
@@ -7859,6 +7863,7 @@ flow_hw_set_vlan_vid(struct rte_eth_dev *dev,
ra[set_vlan_vid_ix].conf = spec;
rm[set_vlan_vid_ix].type = RTE_FLOW_ACTION_TYPE_MODIFY_FIELD;
rm[set_vlan_vid_ix].conf = mask;
+   return 0;
 }
 
 static __rte_always_inline int
@@ -8104,9 +8109,11 @@ __flow_hw_actions_template_create(struct rte_eth_dev 
*dev,
   tmp_mask,
   &ra, &rm,
   act_num);
-   flow_hw_set_vlan_vid(dev, ra, rm,
-&set_vlan_vid_spec, &set_vlan_vid_mask,
-set_vlan_vid_ix);
+   ret = flow_hw_set_vlan_vid(dev, ra, rm,
+  &set_vlan_vid_spec, 
&set_vlan_vid_mask,
+  set_vlan_vid_ix, error);
+   if (ret)
+   goto error;
action_flags |= MLX5_FLOW_ACTION_MODIFY_FIELD;
}
if (action_flags & MLX5_FLOW_ACTION_QUOTA) {
@@ -13744,6 +13751,10 @@ flow_nta_build_template_mask(const struct 
rte_flow_action actions[],
action->conf)->definition;
mask->conf = conf;
break;
+   case RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID:
+   memset(conf, 0xff, sizeof(struct 
rte_flow_action_of_set_vlan_vid));
+   mask->conf = conf;
+   break;
default:
break;
}
-- 
2.21.0



[PATCH 2/2] net/mlx5: fix error info in actions construct

2025-02-27 Thread Maayan Kashani
In some cases in debug it misses the error info.
Fix to update the error structure.

Fixes: 654ebd8cb7a3 ("net/mlx5: support flow table resizing")
Cc: sta...@dpdk.org

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/mlx5_flow_hw.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c
index ec047e855e3..1820b79d229 100644
--- a/drivers/net/mlx5/mlx5_flow_hw.c
+++ b/drivers/net/mlx5/mlx5_flow_hw.c
@@ -3615,7 +3615,8 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
 
mp_segment = mlx5_multi_pattern_segment_find(table, 
flow->res_idx);
if (!mp_segment || !mp_segment->mhdr_action)
-   return -1;
+   return rte_flow_error_set(error, EINVAL, 
RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, "No modify header 
action found");
rule_acts[pos].action = mp_segment->mhdr_action;
/* offset is relative to DR action */
rule_acts[pos].modify_header.offset =
@@ -3946,8 +3947,8 @@ flow_hw_actions_construct(struct rte_eth_dev *dev,
 
 error:
flow_hw_release_actions(dev, queue, flow);
-   rte_errno = EINVAL;
-   return -rte_errno;
+   return rte_flow_error_set(error, EINVAL, 
RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
+ NULL, "Action construction failed");
 }
 
 static const struct rte_flow_item *
-- 
2.21.0



[PATCH] net/mlx5: fix GTP flags matching

2025-02-27 Thread Maayan Kashani
Support gtp flags in non template on top of HWS.
Currently, only extension flag was supported,
Added support to all bits under v_pt_rsv_flags.

Fixes: c55c2bf35333 ("net/mlx5/hws: add definer layer")
Cc: sta...@dpdk.org

Signed-off-by: Maayan Kashani 
Acked-by: Dariusz Sosnowski 
---
 drivers/net/mlx5/hws/mlx5dr_definer.c | 12 ++--
 drivers/net/mlx5/hws/mlx5dr_definer.h | 18 --
 2 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c 
b/drivers/net/mlx5/hws/mlx5dr_definer.c
index 98d670fc1ce..d7799888b1f 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.c
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
@@ -199,7 +199,7 @@ struct mlx5dr_definer_conv_data {
X(SET,  gtp_udp_port,   UDP_GTPU_PORT,  
rte_flow_item_gtp) \
X(SET_BE32, gtp_teid,   v->hdr.teid,
rte_flow_item_gtp) \
X(SET,  gtp_msg_type,   v->hdr.msg_type,
rte_flow_item_gtp) \
-   X(SET,  gtp_ext_flag,   !!v->hdr.gtp_hdr_info,  
rte_flow_item_gtp) \
+   X(SET,  gtp_flags,  v->hdr.gtp_hdr_info,
rte_flow_item_gtp) \
X(SET,  gtp_next_ext_hdr,   GTP_PDU_SC, 
rte_flow_item_gtp_psc) \
X(SET,  gtp_ext_hdr_pdu,v->hdr.type,
rte_flow_item_gtp_psc) \
X(SET,  gtp_ext_hdr_qfi,v->hdr.qfi, 
rte_flow_item_gtp_psc) \
@@ -1462,7 +1462,7 @@ mlx5dr_definer_conv_item_gtp(struct 
mlx5dr_definer_conv_data *cd,
if (!m)
return 0;
 
-   if (m->hdr.plen || m->hdr.gtp_hdr_info & 
~MLX5DR_DEFINER_GTP_EXT_HDR_BIT) {
+   if (m->msg_len) {
rte_errno = ENOTSUP;
return rte_errno;
}
@@ -1484,11 +1484,11 @@ mlx5dr_definer_conv_item_gtp(struct 
mlx5dr_definer_conv_data *cd,
rte_errno = ENOTSUP;
return rte_errno;
}
-   fc = &cd->fc[MLX5DR_DEFINER_FNAME_GTP_EXT_FLAG];
+   fc = &cd->fc[MLX5DR_DEFINER_FNAME_GTP_FLAGS];
fc->item_idx = item_idx;
-   fc->tag_set = &mlx5dr_definer_gtp_ext_flag_set;
-   fc->bit_mask = __mlx5_mask(header_gtp, ext_hdr_flag);
-   fc->bit_off = __mlx5_dw_bit_off(header_gtp, ext_hdr_flag);
+   fc->tag_set = &mlx5dr_definer_gtp_flags_set;
+   fc->bit_mask = __mlx5_mask(header_gtp, v_pt_rsv_flags);
+   fc->bit_off = __mlx5_dw_bit_off(header_gtp, v_pt_rsv_flags);
fc->byte_off = caps->format_select_gtpu_dw_0 * DW_SIZE;
}
 
diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.h 
b/drivers/net/mlx5/hws/mlx5dr_definer.h
index 092b1b3b10e..d0c99399ae5 100644
--- a/drivers/net/mlx5/hws/mlx5dr_definer.h
+++ b/drivers/net/mlx5/hws/mlx5dr_definer.h
@@ -110,6 +110,7 @@ enum mlx5dr_definer_fname {
MLX5DR_DEFINER_FNAME_GTP_TEID,
MLX5DR_DEFINER_FNAME_GTP_MSG_TYPE,
MLX5DR_DEFINER_FNAME_GTP_EXT_FLAG,
+   MLX5DR_DEFINER_FNAME_GTP_FLAGS,
MLX5DR_DEFINER_FNAME_GTP_NEXT_EXT_HDR,
MLX5DR_DEFINER_FNAME_GTP_EXT_HDR_PDU,
MLX5DR_DEFINER_FNAME_GTP_EXT_HDR_QFI,
@@ -606,12 +607,17 @@ enum mlx5dr_definer_gtp {
 };
 
 struct mlx5_ifc_header_gtp_bits {
-   u8 version[0x3];
-   u8 proto_type[0x1];
-   u8 reserved1[0x1];
-   u8 ext_hdr_flag[0x1];
-   u8 seq_num_flag[0x1];
-   u8 pdu_flag[0x1];
+   union {
+u8 v_pt_rsv_flags[0x8];
+   struct {
+   u8 version[0x3];
+   u8 proto_type[0x1];
+   u8 reserved1[0x1];
+   u8 ext_hdr_flag[0x1];
+   u8 seq_num_flag[0x1];
+   u8 pdu_flag[0x1];
+   };
+   };
u8 msg_type[0x8];
u8 msg_len[0x8];
u8 teid[0x20];
-- 
2.21.0



RE: [EXTERNAL] Re: [v6 1/5] vhost: skip crypto op fetch before vring init

2025-02-27 Thread Gowrishankar Muthukrishnan
Hi Maxime,

> >
> > You should only unlock at the end of the function, otherwise there is
> > not much protection.
> 
> Ha, and also you should be able to remove:
> __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */ in
> vhost_crypto_process_one_req() once implemented.
> 

Ack.
Thanks,
Gowrishankar.


[PATCH] app/test: fix DMA API tests in IOVA as PA mode

2025-02-27 Thread Bruce Richardson
When running without IOMMU for address translation, i.e. IOVAs are
physical rather than virtual addresses, we need to translate the
pointers to IOVAs for the completion API tests.

Fixes: 9942ebb9c698 ("test/dma: add dmadev API test")
Cc: fengcheng...@huawei.com
Cc: sta...@dpdk.org

Signed-off-by: Bruce Richardson 
---
 app/test/test_dmadev_api.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/app/test/test_dmadev_api.c b/app/test/test_dmadev_api.c
index d40c05cfbf..fb49fcb56b 100644
--- a/app/test/test_dmadev_api.c
+++ b/app/test/test_dmadev_api.c
@@ -515,7 +515,9 @@ test_dma_completed(void)
setup_memory();
 
/* Check enqueue without submit */
-   ret = rte_dma_copy(test_dev_id, 0, (rte_iova_t)src, (rte_iova_t)dst,
+   ret = rte_dma_copy(test_dev_id, 0,
+  rte_malloc_virt2iova(src),
+  rte_malloc_virt2iova(dst),
   TEST_MEMCPY_SIZE, 0);
RTE_TEST_ASSERT_EQUAL(ret, 0, "Failed to enqueue copy, %d", ret);
rte_delay_us_sleep(TEST_WAIT_US_VAL);
@@ -537,7 +539,9 @@ test_dma_completed(void)
setup_memory();
 
/* Check for enqueue with submit */
-   ret = rte_dma_copy(test_dev_id, 0, (rte_iova_t)src, (rte_iova_t)dst,
+   ret = rte_dma_copy(test_dev_id, 0,
+  rte_malloc_virt2iova(src),
+  rte_malloc_virt2iova(dst),
   TEST_MEMCPY_SIZE, RTE_DMA_OP_FLAG_SUBMIT);
RTE_TEST_ASSERT_EQUAL(ret, 1, "Failed to enqueue copy, %d", ret);
rte_delay_us_sleep(TEST_WAIT_US_VAL);
@@ -572,7 +576,9 @@ test_dma_completed_status(void)
RTE_TEST_ASSERT_SUCCESS(ret, "Failed to start, %d", ret);
 
/* Check for enqueue with submit */
-   ret = rte_dma_copy(test_dev_id, 0, (rte_iova_t)src, (rte_iova_t)dst,
+   ret = rte_dma_copy(test_dev_id, 0,
+  rte_malloc_virt2iova(src),
+  rte_malloc_virt2iova(dst),
   TEST_MEMCPY_SIZE, RTE_DMA_OP_FLAG_SUBMIT);
RTE_TEST_ASSERT_EQUAL(ret, 0, "Failed to enqueue copy, %d", ret);
rte_delay_us_sleep(TEST_WAIT_US_VAL);
@@ -591,7 +597,9 @@ test_dma_completed_status(void)
RTE_TEST_ASSERT_EQUAL(cpl_ret, 0, "Failed to completed status");
 
/* Check for enqueue with submit again */
-   ret = rte_dma_copy(test_dev_id, 0, (rte_iova_t)src, (rte_iova_t)dst,
+   ret = rte_dma_copy(test_dev_id, 0,
+  rte_malloc_virt2iova(src),
+  rte_malloc_virt2iova(dst),
   TEST_MEMCPY_SIZE, RTE_DMA_OP_FLAG_SUBMIT);
RTE_TEST_ASSERT_EQUAL(ret, 1, "Failed to enqueue copy, %d", ret);
rte_delay_us_sleep(TEST_WAIT_US_VAL);
-- 
2.43.0



[v7 4/5] vhost: support asymmetric RSA crypto ops

2025-02-27 Thread Gowrishankar Muthukrishnan
Support asymmetric RSA crypto operations in vhost-user.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 doc/guides/rel_notes/release_25_03.rst |   3 +
 lib/vhost/vhost_crypto.c   | 486 +++--
 lib/vhost/virtio_crypto.h  |  67 
 3 files changed, 521 insertions(+), 35 deletions(-)

diff --git a/doc/guides/rel_notes/release_25_03.rst 
b/doc/guides/rel_notes/release_25_03.rst
index 8867a4bd74..087a407337 100644
--- a/doc/guides/rel_notes/release_25_03.rst
+++ b/doc/guides/rel_notes/release_25_03.rst
@@ -151,6 +151,9 @@ New Features
 
   See the :doc:`../compressdevs/zsda` guide for more details on the new driver.
 
+* **Updated vhost library.**
+
+  Updated vhost library to support RSA crypto operations.
 
 Removed Items
 -
diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index bfc67a724b..5bd9737615 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -55,6 +55,14 @@ RTE_LOG_REGISTER_SUFFIX(vhost_crypto_logtype, crypto, INFO);
  */
 #define vhost_crypto_desc vring_desc
 
+struct vhost_crypto_session {
+   union {
+   struct rte_cryptodev_asym_session *asym;
+   struct rte_cryptodev_sym_session *sym;
+   };
+   enum rte_crypto_op_type type;
+};
+
 static int
 cipher_algo_transform(uint32_t virtio_cipher_algo,
enum rte_crypto_cipher_algorithm *algo)
@@ -207,8 +215,10 @@ struct __rte_cache_aligned vhost_crypto {
 
uint64_t last_session_id;
 
-   uint64_t cache_session_id;
-   struct rte_cryptodev_sym_session *cache_session;
+   uint64_t cache_sym_session_id;
+   struct rte_cryptodev_sym_session *cache_sym_session;
+   uint64_t cache_asym_session_id;
+   struct rte_cryptodev_asym_session *cache_asym_session;
/** socket id for the device */
int socket_id;
 
@@ -335,10 +345,11 @@ transform_chain_param(struct rte_crypto_sym_xform *xforms,
 }
 
 static void
-vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
+vhost_crypto_create_sym_sess(struct vhost_crypto *vcrypto,
VhostUserCryptoSessionParam *sess_param)
 {
struct rte_crypto_sym_xform xform1 = {0}, xform2 = {0};
+   struct vhost_crypto_session *vhost_session;
struct rte_cryptodev_sym_session *session;
int ret;
 
@@ -385,42 +396,277 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
return;
}
 
-   /* insert hash to map */
-   if (rte_hash_add_key_data(vcrypto->session_map,
-   &vcrypto->last_session_id, session) < 0) {
+   vhost_session = rte_zmalloc(NULL, sizeof(*vhost_session), 0);
+   if (vhost_session == NULL) {
+   VC_LOG_ERR("Failed to alloc session memory");
+   goto error_exit;
+   }
+
+   vhost_session->type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
+   vhost_session->sym = session;
+
+   /* insert session to map */
+   if ((rte_hash_add_key_data(vcrypto->session_map,
+   &vcrypto->last_session_id, vhost_session) < 0)) {
VC_LOG_ERR("Failed to insert session to hash table");
+   goto error_exit;
+   }
+
+   VC_LOG_INFO("Session %"PRIu64" created for vdev %i.",
+   vcrypto->last_session_id, vcrypto->dev->vid);
+
+   sess_param->session_id = vcrypto->last_session_id;
+   vcrypto->last_session_id++;
+   return;
+
+error_exit:
+   if (rte_cryptodev_sym_session_free(vcrypto->cid, session) < 0)
+   VC_LOG_ERR("Failed to free session");
+
+   sess_param->session_id = -VIRTIO_CRYPTO_ERR;
+   rte_free(vhost_session);
+}
+
+static int
+tlv_decode(uint8_t *tlv, uint8_t type, uint8_t **data, size_t *data_len)
+{
+   size_t tlen = -EINVAL, len;
+
+   if (tlv[0] != type)
+   return -EINVAL;
 
-   if (rte_cryptodev_sym_session_free(vcrypto->cid, session) < 0)
-   VC_LOG_ERR("Failed to free session");
+   if (tlv[1] == 0x82) {
+   len = (tlv[2] << 8) | tlv[3];
+   *data = &tlv[4];
+   tlen = len + 4;
+   } else if (tlv[1] == 0x81) {
+   len = tlv[2];
+   *data = &tlv[3];
+   tlen = len + 3;
+   } else {
+   len = tlv[1];
+   *data = &tlv[2];
+   tlen = len + 2;
+   }
+
+   *data_len = len;
+   return tlen;
+}
+
+static int
+virtio_crypto_asym_rsa_der_to_xform(uint8_t *der, size_t der_len,
+   struct rte_crypto_asym_xform *xform)
+{
+   uint8_t *n = NULL, *e = NULL, *d = NULL, *p = NULL, *q = NULL, *dp = 
NULL,
+   *dq = NULL, *qinv = NULL, *v = NULL, *tlv;
+   size_t nlen, elen, dlen, plen, qlen, dplen, dqlen, qinvlen, vlen;
+   int len;
+
+   RTE_SET_USED(der_len);
+
+   if (der[0] != 0x30)
+   return -EINVAL;
+
+   if (der[1] == 0x82)
+   tlv = &der[4];
+  

[v7 0/5] vhost: add RSA support

2025-02-27 Thread Gowrishankar Muthukrishnan
This patch series supports asymmetric RSA in vhost crypto library.
It also includes changes to improve vhost crypto library:
 * support newer QEMU versions.
 * fix broken vhost_crypto example application.
 * stabilize crypto fastpath operations.

Gowrishankar Muthukrishnan (5):
  vhost: skip crypto op fetch before vring init
  vhost: update vhost_user crypto session parameters
  examples/vhost_crypto: fix user callbacks
  vhost: support asymmetric RSA crypto ops
  examples/vhost_crypto: support asymmetric crypto

 doc/guides/rel_notes/release_25_03.rst|   3 +
 doc/guides/sample_app_ug/vhost_crypto.rst |   5 +
 examples/vhost_crypto/main.c  |  54 ++-
 lib/vhost/vhost_crypto.c  | 524 --
 lib/vhost/vhost_user.h|  33 +-
 lib/vhost/virtio_crypto.h |  67 +++
 6 files changed, 623 insertions(+), 63 deletions(-)

-- 
2.25.1



[v7 1/5] vhost: skip crypto op fetch before vring init

2025-02-27 Thread Gowrishankar Muthukrishnan
Until virtio avail ring is initialized (by VHOST_USER_SET_VRING_ADDR),
worker thread should not try to fetch crypto op, which would lead to
memory fault.

Fixes: 939066d96563 ("vhost/crypto: add public function implementation")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
v7:
 - updated locks in fetch req func.
---
 lib/vhost/vhost_crypto.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index 3dc41a3bd5..3967d68d77 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include "iotlb.h"
 #include "rte_vhost_crypto.h"
 #include "vhost.h"
 #include "vhost_user.h"
@@ -1131,7 +1132,6 @@ vhost_crypto_process_one_req(struct vhost_crypto *vcrypto,
struct vhost_virtqueue *vq, struct rte_crypto_op *op,
struct vring_desc *head, struct vhost_crypto_desc *descs,
uint16_t desc_idx)
-   __rte_no_thread_safety_analysis /* FIXME: requires iotlb_lock? */
 {
struct vhost_crypto_data_req *vc_req = rte_mbuf_to_priv(op->sym->m_src);
struct rte_cryptodev_sym_session *session;
@@ -1580,6 +1580,20 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
 
vq = dev->virtqueue[qid];
 
+   if (unlikely(vq == NULL)) {
+   VC_LOG_ERR("Invalid virtqueue %u", qid);
+   return 0;
+   }
+
+   if (unlikely(rte_rwlock_read_trylock(&vq->access_lock) != 0))
+   return 0;
+
+   vhost_user_iotlb_rd_lock(vq);
+   if (unlikely(!vq->access_ok)) {
+   VC_LOG_DBG("Virtqueue %u vrings not yet initialized", qid);
+   goto out_unlock;
+   }
+
avail_idx = *((volatile uint16_t *)&vq->avail->idx);
start_idx = vq->last_used_idx;
count = avail_idx - start_idx;
@@ -1587,7 +1601,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
count = RTE_MIN(count, nb_ops);
 
if (unlikely(count == 0))
-   return 0;
+   goto out_unlock;
 
/* for zero copy, we need 2 empty mbufs for src and dst, otherwise
 * we need only 1 mbuf as src and dst
@@ -1597,7 +1611,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
if (unlikely(rte_mempool_get_bulk(vcrypto->mbuf_pool,
(void **)mbufs, count * 2) < 0)) {
VC_LOG_ERR("Insufficient memory");
-   return 0;
+   goto out_unlock;
}
 
for (i = 0; i < count; i++) {
@@ -1627,7 +1641,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
if (unlikely(rte_mempool_get_bulk(vcrypto->mbuf_pool,
(void **)mbufs, count) < 0)) {
VC_LOG_ERR("Insufficient memory");
-   return 0;
+   goto out_unlock;
}
 
for (i = 0; i < count; i++) {
@@ -1656,6 +1670,10 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
 
vq->last_used_idx += i;
 
+out_unlock:
+   vhost_user_iotlb_rd_unlock(vq);
+   rte_rwlock_read_unlock(&vq->access_lock);
+
return i;
 }
 
-- 
2.25.1



[v7 5/5] examples/vhost_crypto: support asymmetric crypto

2025-02-27 Thread Gowrishankar Muthukrishnan
Support asymmetric crypto operations.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 doc/guides/sample_app_ug/vhost_crypto.rst |  5 +++
 examples/vhost_crypto/main.c  | 50 +--
 2 files changed, 43 insertions(+), 12 deletions(-)

diff --git a/doc/guides/sample_app_ug/vhost_crypto.rst 
b/doc/guides/sample_app_ug/vhost_crypto.rst
index 7ae7addac4..b00f2bf3ae 100644
--- a/doc/guides/sample_app_ug/vhost_crypto.rst
+++ b/doc/guides/sample_app_ug/vhost_crypto.rst
@@ -33,6 +33,7 @@ Start the vhost_crypto example
--socket-file lcore,PATH
[--zero-copy]
[--guest-polling]
+   [--asymmetric-crypto]
 
 where,
 
@@ -54,6 +55,10 @@ where,
   guest works in polling mode, thus will NOT notify the guest completion of
   processing.
 
+* asymmetric-crypto: the presence of this item means the application
+  can handle the asymmetric crypto requests. When this option is used,
+  symmetric crypto requests can not be handled by the application.
+
 The application requires that crypto devices capable of performing
 the specified crypto operation are available on application initialization.
 This means that HW crypto device/s must be bound to a DPDK driver or
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index b1fe4120b9..8bdfc40c4b 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -59,6 +59,7 @@ struct vhost_crypto_options {
uint32_t nb_los;
uint32_t zero_copy;
uint32_t guest_polling;
+   bool asymmetric_crypto;
 } options;
 
 enum {
@@ -70,6 +71,8 @@ enum {
OPT_ZERO_COPY_NUM,
 #define OPT_POLLING "guest-polling"
OPT_POLLING_NUM,
+#define OPT_ASYM"asymmetric-crypto"
+   OPT_ASYM_NUM,
 };
 
 #define NB_SOCKET_FIELDS   (2)
@@ -202,9 +205,10 @@ vhost_crypto_usage(const char *prgname)
"  --%s ,SOCKET-FILE-PATH\n"
"  --%s (lcore,cdev_id,queue_id)[,(lcore,cdev_id,queue_id)]\n"
"  --%s: zero copy\n"
-   "  --%s: guest polling\n",
+   "  --%s: guest polling\n"
+   "  --%s: asymmetric crypto\n",
prgname, OPT_SOCKET_FILE, OPT_CONFIG,
-   OPT_ZERO_COPY, OPT_POLLING);
+   OPT_ZERO_COPY, OPT_POLLING, OPT_ASYM);
 }
 
 static int
@@ -223,6 +227,8 @@ vhost_crypto_parse_args(int argc, char **argv)
NULL, OPT_ZERO_COPY_NUM},
{OPT_POLLING, no_argument,
NULL, OPT_POLLING_NUM},
+   {OPT_ASYM, no_argument,
+   NULL, OPT_ASYM_NUM},
{NULL, 0, 0, 0}
};
 
@@ -262,6 +268,10 @@ vhost_crypto_parse_args(int argc, char **argv)
options.guest_polling = 1;
break;
 
+   case OPT_ASYM_NUM:
+   options.asymmetric_crypto = true;
+   break;
+
default:
vhost_crypto_usage(prgname);
return -EINVAL;
@@ -376,6 +386,7 @@ vhost_crypto_worker(void *arg)
int callfds[VIRTIO_CRYPTO_MAX_NUM_BURST_VQS];
uint32_t lcore_id = rte_lcore_id();
uint32_t burst_size = MAX_PKT_BURST;
+   enum rte_crypto_op_type cop_type;
uint32_t i, j, k;
uint32_t to_fetch, fetched;
 
@@ -383,9 +394,13 @@ vhost_crypto_worker(void *arg)
 
RTE_LOG(INFO, USER1, "Processing on Core %u started\n", lcore_id);
 
+   cop_type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
+   if (options.asymmetric_crypto)
+   cop_type = RTE_CRYPTO_OP_TYPE_ASYMMETRIC;
+
for (i = 0; i < NB_VIRTIO_QUEUES; i++) {
if (rte_crypto_op_bulk_alloc(info->cop_pool,
-   RTE_CRYPTO_OP_TYPE_SYMMETRIC, ops[i],
+   cop_type, ops[i],
burst_size) < burst_size) {
RTE_LOG(ERR, USER1, "Failed to alloc cops\n");
ret = -1;
@@ -411,12 +426,11 @@ vhost_crypto_worker(void *arg)
fetched);
if (unlikely(rte_crypto_op_bulk_alloc(
info->cop_pool,
-   RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+   cop_type,
ops[j], fetched) < fetched)) {
RTE_LOG(ERR, USER1, "Failed realloc\n");
return -1;
}
-
fetched = rte_cryptodev_dequeue_burst(
info->cid, info->qid,
ops_deq[j], RTE_MIN(burst_size,
@@ -477,6 +491,7 @@ m

[v7 2/5] vhost: update vhost_user crypto session parameters

2025-02-27 Thread Gowrishankar Muthukrishnan
As per requirements on vhost_user spec, session id should be
located at the end of session parameter.

Update VhostUserCryptoSessionParam structure to support newer QEMU
versions (v9). Due to additional parameters added in QEMU,
received payload from QEMU would be larger than existing payload.
Hence, it would break parsing vhost_user messages.

This patch addresses both of the above problems.

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 lib/vhost/vhost_crypto.c | 12 ++--
 lib/vhost/vhost_user.h   | 33 +
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index 3967d68d77..bfc67a724b 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -238,7 +238,7 @@ struct vhost_crypto_data_req {
 
 static int
 transform_cipher_param(struct rte_crypto_sym_xform *xform,
-   VhostUserCryptoSessionParam *param)
+   VhostUserCryptoSymSessionParam *param)
 {
int ret;
 
@@ -274,7 +274,7 @@ transform_cipher_param(struct rte_crypto_sym_xform *xform,
 
 static int
 transform_chain_param(struct rte_crypto_sym_xform *xforms,
-   VhostUserCryptoSessionParam *param)
+   VhostUserCryptoSymSessionParam *param)
 {
struct rte_crypto_sym_xform *xform_cipher, *xform_auth;
int ret;
@@ -342,10 +342,10 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
struct rte_cryptodev_sym_session *session;
int ret;
 
-   switch (sess_param->op_type) {
+   switch (sess_param->u.sym_sess.op_type) {
case VIRTIO_CRYPTO_SYM_OP_NONE:
case VIRTIO_CRYPTO_SYM_OP_CIPHER:
-   ret = transform_cipher_param(&xform1, sess_param);
+   ret = transform_cipher_param(&xform1, &sess_param->u.sym_sess);
if (unlikely(ret)) {
VC_LOG_ERR("Error transform session msg (%i)", ret);
sess_param->session_id = ret;
@@ -353,7 +353,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
}
break;
case VIRTIO_CRYPTO_SYM_OP_ALGORITHM_CHAINING:
-   if (unlikely(sess_param->hash_mode !=
+   if (unlikely(sess_param->u.sym_sess.hash_mode !=
VIRTIO_CRYPTO_SYM_HASH_MODE_AUTH)) {
sess_param->session_id = -VIRTIO_CRYPTO_NOTSUPP;
VC_LOG_ERR("Error transform session message (%i)",
@@ -363,7 +363,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
 
xform1.next = &xform2;
 
-   ret = transform_chain_param(&xform1, sess_param);
+   ret = transform_chain_param(&xform1, &sess_param->u.sym_sess);
if (unlikely(ret)) {
VC_LOG_ERR("Error transform session message (%i)", ret);
sess_param->session_id = ret;
diff --git a/lib/vhost/vhost_user.h b/lib/vhost/vhost_user.h
index 9a905ee5f4..ef486545ba 100644
--- a/lib/vhost/vhost_user.h
+++ b/lib/vhost/vhost_user.h
@@ -99,11 +99,10 @@ typedef struct VhostUserLog {
 /* Comply with Cryptodev-Linux */
 #define VHOST_USER_CRYPTO_MAX_HMAC_KEY_LENGTH  512
 #define VHOST_USER_CRYPTO_MAX_CIPHER_KEY_LENGTH64
+#define VHOST_USER_CRYPTO_MAX_KEY_LENGTH   1024
 
 /* Same structure as vhost-user backend session info */
-typedef struct VhostUserCryptoSessionParam {
-   int64_t session_id;
-   uint32_t op_code;
+typedef struct VhostUserCryptoSymSessionParam {
uint32_t cipher_algo;
uint32_t cipher_key_len;
uint32_t hash_algo;
@@ -114,10 +113,36 @@ typedef struct VhostUserCryptoSessionParam {
uint8_t dir;
uint8_t hash_mode;
uint8_t chaining_dir;
-   uint8_t *ciphe_key;
+   uint8_t *cipher_key;
uint8_t *auth_key;
uint8_t cipher_key_buf[VHOST_USER_CRYPTO_MAX_CIPHER_KEY_LENGTH];
uint8_t auth_key_buf[VHOST_USER_CRYPTO_MAX_HMAC_KEY_LENGTH];
+} VhostUserCryptoSymSessionParam;
+
+
+typedef struct VhostUserCryptoAsymRsaParam {
+   uint32_t padding_algo;
+   uint32_t hash_algo;
+} VhostUserCryptoAsymRsaParam;
+
+typedef struct VhostUserCryptoAsymSessionParam {
+   uint32_t algo;
+   uint32_t key_type;
+   uint32_t key_len;
+   uint8_t *key;
+   union {
+   VhostUserCryptoAsymRsaParam rsa;
+   } u;
+   uint8_t key_buf[VHOST_USER_CRYPTO_MAX_KEY_LENGTH];
+} VhostUserCryptoAsymSessionParam;
+
+typedef struct VhostUserCryptoSessionParam {
+   uint32_t op_code;
+   union {
+   VhostUserCryptoSymSessionParam sym_sess;
+   VhostUserCryptoAsymSessionParam asym_sess;
+   } u;
+   int64_t session_id;
 } VhostUserCryptoSessionParam;
 
 typedef struct VhostUserVringArea {
-- 
2.25.1



[v7 3/5] examples/vhost_crypto: fix user callbacks

2025-02-27 Thread Gowrishankar Muthukrishnan
In order to handle new vhost user connection, use new_connection
and destroy_connection callbacks.

Fixes: f5188211c721 ("examples/vhost_crypto: add sample application")
Cc: sta...@dpdk.org

Signed-off-by: Gowrishankar Muthukrishnan 
Acked-by: Akhil Goyal 
---
 examples/vhost_crypto/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 558c09a60f..b1fe4120b9 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -362,8 +362,8 @@ destroy_device(int vid)
 }
 
 static const struct rte_vhost_device_ops virtio_crypto_device_ops = {
-   .new_device =  new_device,
-   .destroy_device = destroy_device,
+   .new_connection =  new_device,
+   .destroy_connection = destroy_device,
 };
 
 static int
-- 
2.25.1