RE: [PATCH v7] net/bonding: another fix to LACP mempool size
Hi Ferruh, Gaoxiang
From: Ferruh Yigit
> On 3/28/2022 4:16 PM, Gaoxiang Liu wrote:
> > The following log message may appear after a slave is idle(or nearly
> > idle)
> > for a few minutes:"PMD: Failed to allocate LACP packet from pool".
> > And bond mode 4 negotiation may fail.
> >
> > Problem:When bond mode 4 has been chosed and delicated queue has not
> > been enable, all mbufs from a slave' private pool(used exclusively for
> > transmitting LACPDUs) have been allocated in interrupt thread, and are
> > still sitting in the device's tx descriptor ring and other cores'
> > mempool caches in fwd thread.
> > Thus the interrupt thread can not alloc LACP packet from pool.
> >
> > Solution: Ensure that each slave'tx (LACPDU) mempool owns more than
> > n-tx-queues * n-tx-descriptor + fwd_core_num *
> > per-core-mmempool-flush-threshold mbufs.
> >
> > Note that the LACP tx machine fuction is the only code that allocates
> > from a slave's private pool. It runs in the context of the interrupt
> > thread, and thus it has no mempool cache of its own.
> >
> > Signed-off-by: Gaoxiang Liu
> >
> > ---
> > v2:
> > * Fixed compile issues.
> >
> > v3:
> > * delete duplicate code.
> >
> > v4;
> > * Fixed some issues.
> > 1. total_tx_desc should use +=
> > 2. add detailed logs
> >
> > v5:
> > * Fixed some issues.
> > 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c 2.
> use
> > RTE_MIN
> >
> > v6:
> > * add a comment of CACHE_FLUSHTHRESH_MULTIPLIER macro
> >
> > v7:
> > * Fixed some issues.
> > 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_mempool.h
> > ---
> > drivers/net/bonding/rte_eth_bond_8023ad.c | 7 ---
> > lib/mempool/rte_mempool.h | 2 ++
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
> > b/drivers/net/bonding/rte_eth_bond_8023ad.c
> > index ca50583d62..f7f6828126 100644
> > --- a/drivers/net/bonding/rte_eth_bond_8023ad.c
> > +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
> > @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct
> rte_eth_dev *bond_dev,
> > uint32_t total_tx_desc;
> > struct bond_tx_queue *bd_tx_q;
> > uint16_t q_id;
> > + uint32_t cache_size;
> >
> > /* Given slave mus not be in active list */
> > RTE_ASSERT(find_slave_by_id(internals->active_slaves,
> > @@ -1100,11 +1101,11 @@ bond_mode_8023ad_activate_slave(struct
> rte_eth_dev *bond_dev,
> > total_tx_desc += bd_tx_q->nb_tx_desc;
> > }
> >
> > + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32);
> > + total_tx_desc += rte_lcore_count() * cache_size *
> > + RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER;
> > snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool",
> slave_id);
> > port->mbuf_pool = rte_pktmbuf_pool_create(mem_name,
> total_tx_desc,
> > - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ?
> > - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE,
> > - 0, element_size, socket_id);
> > + cache_size, 0, element_size, socket_id);
> >
> > /* Any memory allocation failure in initialization is critical because
> >* resources can't be free, so reinitialization is impossible.
> > */ diff --git a/lib/mempool/rte_mempool.h
> b/lib/mempool/rte_mempool.h
> > index 1e7a3c1527..fa15ed710f 100644
> > --- a/lib/mempool/rte_mempool.h
> > +++ b/lib/mempool/rte_mempool.h
> > @@ -56,6 +56,8 @@
> > extern "C" {
> > #endif
> >
> > +#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5
> > +
>
> This change seems already get some comments and changes in previous
> versions.
>
> I also thought why we are adding a new macro to the mempool for a bonding
> driver update, but that is not the whole picture.
> There is an existing 'CACHE_FLUSHTHRESH_MULTIPLIER' macro in mempool,
> this patch wants to use it but that macro is not exposed.
> And I can see there is other user of that macros (mlx5_rxq.c [1]) suffering
> from same problem.
>
> So, what do you think having two patches,
> - first one is only for mempool update, which removes the
> 'CACHE_FLUSHTHRESH_MULTIPLIER' from 'rte_mempool.c', adds
> 'RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER' to 'rte_mempool.h' as
> this patch does, and update existing usage.
>
> - second patch just updates the bonding driver and use the new
> 'RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER' macro
>
>
>
> [1] @Matan, @Slava,
> 'mlx5_rxq.c', comment mentions that it intends to use
> 'CACHE_FLUSHTHRESH_MULTIPLIER' but can't access it and use a hardcoded
> value (2). But the hard coded value and macro values doesn't match, is it
> intentional.
I think it is to pass the cache size check into mempool API.
> When 'RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER' is exposed in
> header, can it be replaced with hard coded value in the driver?
Yes, we need to be careful with the types when doing the calculation to ensure
it will continue to pass the mempool check.
For sure, we can help and validate here.
Matan
>
Re: [PATCH v4 1/3] eal: add basic thread ID and current thread identifier API
2022-04-26 00:50 (UTC-0700), Tyler Retzlaff: > Provide a portable type-safe thread identifier. > Provide rte_thread_self for obtaining current thread identifier. > > Signed-off-by: Narcisa Vasile > Signed-off-by: Tyler Retzlaff Acked-by: Dmitry Kozlyuk
Re: [PATCH v4 2/3] eal: implement functions for get/set thread affinity
2022-04-26 00:50 (UTC-0700), Tyler Retzlaff:
> Implement functions for getting/setting thread affinity.
> Threads can be pinned to specific cores by setting their
> affinity attribute.
>
> Windows error codes are translated to errno-style error codes.
> The possible return values are chosen so that we have as
> much semantic compatibility between platforms as possible.
>
> note: convert_cpuset_to_affinity has a limitation that all cpus of
> the set belong to the same processor group.
>
> Signed-off-by: Narcisa Vasile
> Signed-off-by: Tyler Retzlaff
Acked-by: Dmitry Kozlyuk
with two minor issues below.
> +static int
> +eal_query_group_affinity(void)
> +{
> + SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX *infos = NULL;
> + unsigned int *cpu_count = &cpu_map.cpu_count;
> + DWORD infos_size = 0;
> + int ret = 0;
> + USHORT group_count;
> + KAFFINITY affinity;
> + USHORT group_no;
> + unsigned int i;
> +
> + if (!GetLogicalProcessorInformationEx(RelationGroup, NULL,
> + &infos_size)) {
> + DWORD error = GetLastError();
> + if (error != ERROR_INSUFFICIENT_BUFFER) {
> + log_early("Cannot get group information size, error
> %lu\n", error);
This code is now called not only at initialization,
but also after the logging is set up,
in which case this line will not go into a redirected destination.
I think there should not be log_early() at all in EAL,
rte_log() could work from the very beginning.
We're not in the kernel, stderr is available at once.
So I would work around with a static flag maybe.
[...]
> +static int
> +convert_cpuset_to_affinity(const rte_cpuset_t *cpuset,
> + PGROUP_AFFINITY affinity)
> +{
> + int ret = 0;
> + PGROUP_AFFINITY cpu_affinity = NULL;
> + unsigned int cpu_idx;
> +
> + memset(affinity, 0, sizeof(GROUP_AFFINITY));
> + affinity->Group = (USHORT)-1;
> +
> + /* Check that all cpus of the set belong to the same processor group and
> + * accumulate thread affinity to be applied.
> + */
> + for (cpu_idx = 0; cpu_idx < CPU_SETSIZE; cpu_idx++) {
> + if (!CPU_ISSET(cpu_idx, cpuset))
> + continue;
> +
> + cpu_affinity = eal_get_cpu_affinity(cpu_idx);
> +
> + if (affinity->Group == (USHORT)-1) {
> + affinity->Group = cpu_affinity->Group;
> + } else if (affinity->Group != cpu_affinity->Group) {
> + ret = ENOTSUP;
Maybe worth a dedug log because the limitation is non-obvious.
Re: [PATCH v4 3/3] test/threads: add unit test for thread API
2022-04-26 00:50 (UTC-0700), Tyler Retzlaff:
> Establish unit test for testing thread api. Initial unit tests
> for rte_thread_{get,set}_affinity_by_id().
>
> Signed-off-by: Narcisa Vasile
> Signed-off-by: Tyler Retzlaff
> ---
> app/test/meson.build| 2 ++
> app/test/test_threads.c | 89
> +
> 2 files changed, 91 insertions(+)
> create mode 100644 app/test/test_threads.c
>
> diff --git a/app/test/meson.build b/app/test/meson.build
> index 5fc1dd1..5a9d69b 100644
> --- a/app/test/meson.build
> +++ b/app/test/meson.build
> @@ -133,6 +133,7 @@ test_sources = files(
> 'test_tailq.c',
> 'test_thash.c',
> 'test_thash_perf.c',
> +'test_threads.c',
> 'test_timer.c',
> 'test_timer_perf.c',
> 'test_timer_racecond.c',
> @@ -238,6 +239,7 @@ fast_tests = [
> ['reorder_autotest', true],
> ['service_autotest', true],
> ['thash_autotest', true],
> +['threads_autotest', true],
> ['trace_autotest', true],
> ]
>
> diff --git a/app/test/test_threads.c b/app/test/test_threads.c
> new file mode 100644
> index 000..0ca6745
> --- /dev/null
> +++ b/app/test/test_threads.c
> @@ -0,0 +1,89 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright (C) 2022 Microsoft Corporation
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "test.h"
> +
> +RTE_LOG_REGISTER(threads_logtype_test, test.threads, INFO);
> +
> +static uint32_t thread_id_ready;
> +
> +static void *
> +thread_main(void *arg)
> +{
> + *(rte_thread_t *)arg = rte_thread_self();
> + __atomic_store_n(&thread_id_ready, 1, __ATOMIC_RELEASE);
> +
> + return NULL;
> +}
> +
> +static int
> +test_thread_affinity(void)
> +{
> + pthread_t id;
> + rte_thread_t thread_id;
> +
> + RTE_TEST_ASSERT(pthread_create(&id, NULL, thread_main, &thread_id) == 0,
> + "Failed to create thread");
> +
> + while (__atomic_load_n(&thread_id_ready, __ATOMIC_ACQUIRE) == 0)
> + ;
> +
> + rte_cpuset_t cpuset0;
Variables should be declared at the beginning of the block.
> + RTE_TEST_ASSERT(rte_thread_get_affinity_by_id(thread_id, &cpuset0) == 0,
> + "Failed to get thread affinity");
> +
> + rte_cpuset_t cpuset1;
> + RTE_TEST_ASSERT(rte_thread_get_affinity_by_id(thread_id, &cpuset1) == 0,
> + "Failed to get thread affinity");
> + RTE_TEST_ASSERT(memcmp(&cpuset0, &cpuset1, sizeof(rte_cpuset_t)) == 0,
> + "Affinity should be stable");
> +
> + RTE_TEST_ASSERT(rte_thread_set_affinity_by_id(thread_id, &cpuset1) == 0,
> + "Failed to set thread affinity");
> + RTE_TEST_ASSERT(rte_thread_get_affinity_by_id(thread_id, &cpuset0) == 0,
> + "Failed to get thread affinity");
> + RTE_TEST_ASSERT(memcmp(&cpuset0, &cpuset1, sizeof(rte_cpuset_t)) == 0,
> + "Affinity should be stable");
> +
> + size_t i;
> + for (i = 1; i < CPU_SETSIZE; i++)
> + if (CPU_ISSET(i, &cpuset0)) {
> + CPU_ZERO(&cpuset0);
> + CPU_SET(i, &cpuset0);
> +
> + break;
> + }
> + RTE_TEST_ASSERT(rte_thread_set_affinity_by_id(thread_id, &cpuset0) == 0,
> + "Failed to set thread affinity");
> + RTE_TEST_ASSERT(rte_thread_get_affinity_by_id(thread_id, &cpuset1) == 0,
> + "Failed to get thread affinity");
> + RTE_TEST_ASSERT(memcmp(&cpuset0, &cpuset1, sizeof(rte_cpuset_t)) == 0,
> + "Affinity should be stable");
The message is not really relevant to the check done.
"Retrieved affinity differs from requested"?
I think this is the only check worth keeping in this test.
The fist one is speculative: if we expect that a wrong implementation may
change affinity sporadically, the test can't prove it doesn't.
The second one isn't stronger than this one.
> +
> + return 0;
> +}
> +
> +static struct unit_test_suite threads_test_suite = {
> + .suite_name = "threads autotest",
> + .setup = NULL,
> + .teardown = NULL,
> + .unit_test_cases = {
> + TEST_CASE(test_thread_affinity),
> + TEST_CASES_END()
> + }
> +};
> +
> +static int
> +test_threads(void)
> +{
> + return unit_test_suite_runner(&threads_test_suite);
> +}
> +
> +REGISTER_TEST_COMMAND(threads_autotest, test_threads);
[PATCH] crypto/mlx5: support plaintext keys
Using crypto devs requires the user to log in and the supplied DEK to be
encrypted with a KEK (keys encryption key).
KEK is burned once on the nic, along with credentials for users,
and for a user to log in, he is needed to supply his creds wrapped with
the KEK.
A device comes out of the Mellanox factory with a pre-defined import
method for each algorithm. The defined method could be wrapped
mode, so the device can be used as described above, or
plaintext mode, without the need to log in and wrap supplied DEKs.
Support crypto operations with the plaintext import method.
Signed-off-by: Raja Zidane
Acked-by: Matan Azrad
---
doc/guides/cryptodevs/mlx5.rst| 17 --
drivers/common/mlx5/mlx5_devx_cmds.c | 13 ++--
drivers/common/mlx5/mlx5_devx_cmds.h | 1 +
drivers/common/mlx5/mlx5_prm.h| 29 +
drivers/crypto/mlx5/mlx5_crypto.c | 43 +++-
drivers/crypto/mlx5/mlx5_crypto.h | 3 +-
drivers/crypto/mlx5/mlx5_crypto_dek.c | 47 +++
7 files changed, 117 insertions(+), 36 deletions(-)
diff --git a/doc/guides/cryptodevs/mlx5.rst b/doc/guides/cryptodevs/mlx5.rst
index ef47aa65dd..93084cc506 100644
--- a/doc/guides/cryptodevs/mlx5.rst
+++ b/doc/guides/cryptodevs/mlx5.rst
@@ -35,6 +35,10 @@ Configuration
See the :ref:`mlx5 common configuration `.
+A device comes out of Mellanox factory with pre-defined import methods.
+There are two possible import methods: wrapped or plaintext.
+
+In case the device is in wrapped mode, it needs to be moved to crypto
operational mode.
In order to move the device to crypto operational mode, credential and KEK
(Key Encrypting Key) should be set as the first step.
The credential will be used by the software in order to perform crypto login,
and the KEK is
@@ -89,10 +93,17 @@ The mlxreg dedicated tool should be used as follows:
The "wrapped_crypto_operational" value will be "0x0001" if the mode was
successfully changed to operational mode.
+On the other hand, in case of plaintext mode, there is no need for all the
above,
+DEK is passed in plaintext without keytag.
+
The mlx5 crypto PMD can be verified by running the test application::
+Wrapped mode:
+ dpdk-test -c 1 -n 1 -w ,class=crypto,wcs_file=
+ RTE>>cryptodev_mlx5_autotest
- dpdk-test -c 1 -n 1 -w ,class=crypto,wcs_file=
- RTE>>cryptodev_mlx5_autotest
+Plaintext mode:
+ dpdk-test -c 1 -n 1 -w ,class=crypto
+ RTE>>cryptodev_mlx5_autotest
Driver options
@@ -101,7 +112,7 @@ Driver options
Please refer to :ref:`mlx5 common options `
for an additional list of options shared with other mlx5 drivers.
-- ``wcs_file`` parameter [string] - mandatory
+- ``wcs_file`` parameter [string] - mandatory in wrapped mode
File path including only the wrapped credential in string format of
hexadecimal
numbers, represent 48 bytes (8 bytes IV added by the AES key wrap algorithm).
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.c
b/drivers/common/mlx5/mlx5_devx_cmds.c
index d02ac2a678..c6bdbc12bb 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.c
+++ b/drivers/common/mlx5/mlx5_devx_cmds.c
@@ -964,12 +964,21 @@ mlx5_devx_cmd_query_hca_attr(void *ctx,
MLX5_GET(cmd_hca_cap, hcattr, umr_modify_entity_size_disabled);
attr->wait_on_time = MLX5_GET(cmd_hca_cap, hcattr, wait_on_time);
attr->crypto = MLX5_GET(cmd_hca_cap, hcattr, crypto);
- if (attr->crypto)
- attr->aes_xts = MLX5_GET(cmd_hca_cap, hcattr, aes_xts);
attr->ct_offload = !!(MLX5_GET64(cmd_hca_cap, hcattr,
general_obj_types) &
MLX5_GENERAL_OBJ_TYPES_CAP_CONN_TRACK_OFFLOAD);
attr->rq_delay_drop = MLX5_GET(cmd_hca_cap, hcattr, rq_delay_drop);
+ if (attr->crypto) {
+ attr->aes_xts = MLX5_GET(cmd_hca_cap, hcattr, aes_xts);
+ hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
+ MLX5_GET_HCA_CAP_OP_MOD_CRYPTO |
+ MLX5_HCA_CAP_OPMOD_GET_CUR);
+ if (!hcattr)
+ return -1;
+ attr->crypto_wrapped_import_method = !!(MLX5_GET(crypto_caps,
+ hcattr, wrapped_import_method)
+ & 1 << 2);
+ }
if (hca_cap_2_sup) {
hcattr = mlx5_devx_get_hca_cap(ctx, in, out, &rc,
MLX5_GET_HCA_CAP_OP_MOD_GENERAL_DEVICE_2 |
diff --git a/drivers/common/mlx5/mlx5_devx_cmds.h
b/drivers/common/mlx5/mlx5_devx_cmds.h
index 1bac18c59d..3747ef9e33 100644
--- a/drivers/common/mlx5/mlx5_devx_cmds.h
+++ b/drivers/common/mlx5/mlx5_devx_cmds.h
@@ -254,6 +254,7 @@ struct mlx5_hca_attr {
uint32_t umr_indirect_mkey_disabled:1;
uint32_t log_min_stride_wqe_sz:5;
uint32_t esw_mgr_vport_id_valid:1; /* E-Switch Mgr vport ID is val
RE: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
> -Original Message-
> From: Akhil Goyal
> Sent: Friday, April 29, 2022 5:47 PM
> To: Gujjar, Abhinandan S ; dev@dpdk.org
> Cc: Anoob Joseph ; Jerin Jacob Kollanukkaran
> ; Jayatheerthan, Jay ;
> Vangati, Narender ; Volodymyr Fialko
>
> Subject: RE: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
>
> Hi Abhinandan,
>
> Please see inline.
> > > +
> > > +void *
> > > +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op) {
> > Null check for op?
>
> Null check can be added, but this a datapath dpdk internal API.
> We do not normally add checks in datapath.
> If you insist, I can add, but before calling this API, PMD/lib would have
> already
> checked for null op.
It is ok for get API. It is better to add the check for set API as it exposed
to user application.
Currently, the set API is validating dev_id. It is better to add a null check
only for set API.
>
> > > + if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
> > > + op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> > > + return rte_cryptodev_sym_session_get_user_data(op->sym-
> > > >session);
> > > + else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
> > > + op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> > > + return op->asym->session->event_mdata;
> > > + else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
> > > + op->private_data_offset)
> > > + return ((uint8_t *)op + op->private_data_offset);
> > > + else
> > > + return NULL;
> > > +}
> > > diff --git a/lib/cryptodev/cryptodev_pmd.h
> > > b/lib/cryptodev/cryptodev_pmd.h index 2b1ce2da2d..7969944b66 100644
> > > --- a/lib/cryptodev/cryptodev_pmd.h
> > > +++ b/lib/cryptodev/cryptodev_pmd.h
> > > @@ -398,6 +398,25 @@ typedef int
> > > (*cryptodev_sym_configure_raw_dp_ctx_t)(
> > > enum rte_crypto_op_sess_type sess_type,
> > > union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
> > >
> > > +/**
> > > + * Typedef that the driver provided to set event crypto meta data.
> > > + *
> > > + * @paramdev Crypto device pointer.
> > > + * @paramsessCrypto or security session.
> > > + * @paramop_type Operation type.
> > > + * @paramsess_type Session type.
> > > + * @paramev_mdataPointer to the event crypto meta data
> > > + * (aka *union rte_event_crypto_metadata*)
> > > + * @return
> > > + * - On success return 0.
> > > + * - On failure return negative integer.
> > > + */
> > > +typedef int (*cryptodev_session_event_mdata_set_t)(
> > > + struct rte_cryptodev *dev, void *sess,
> > > + enum rte_crypto_op_type op_type,
> > > + enum rte_crypto_op_sess_type sess_type,
> > > + void *ev_mdata);
> > > +
> > > /** Crypto device operations function pointer table */ struct
> > > rte_cryptodev_ops {
> > > cryptodev_configure_t dev_configure;/**< Configure device. */
> > > @@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
> > > /**< Initialize raw data path context data. */
> > > };
> > > };
> > > + cryptodev_session_event_mdata_set_t session_ev_mdata_set;
> > > + /**< Set a Crypto or Security session even meta data. */
> > > };
> > >
> > >
> > > @@ -603,6 +624,19 @@ void
> > > cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
> > >const struct rte_cryptodev *dev);
> > >
> > > +/**
> > > + * Get session event meta data (aka *union
> > > +rte_event_crypto_metadata*)
> > > + *
> > > + * @paramoppointer to *rte_crypto_op* structure.
> > > + *
> > > + * @return
> > > + * - On success, pointer to event crypto metadata
> > > + * - On failure, a negative value.
> > > + */
> > > +__rte_internal
> > > +void *
> > > +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
> > > +
> > > static inline void *
> > > get_sym_session_private_data(const struct rte_cryptodev_sym_session
> > *sess,
> > > uint8_t driver_id) {
> > > @@ -636,6 +670,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
> > > /**< Size of private data used when creating mempool */
> > > uint16_t user_data_sz;
> > > /**< Session user data will be placed after sess_data */
> > > + void *event_mdata;
> > > + /**< Event crypto adapter metadata */
> > Add reference to rte_event_crypto_metadata for clarity?
>
> Ok will add the comment.
>
> > > uint8_t padding[3];
> > > uint8_t sess_private_data[0];
> > > };
> > > diff --git a/lib/cryptodev/rte_cryptodev.c
> > > b/lib/cryptodev/rte_cryptodev.c
> > index
> > > 3500a2d470..a070cb2a00 100644
> > > --- a/lib/cryptodev/rte_cryptodev.c
> > > +++ b/lib/cryptodev/rte_cryptodev.c
> > > @@ -2051,6 +2051,9 @@ rte_cryptodev_asym_session_free(uint8_t
> > > dev_id, void *sess)
> > >
> > > dev->dev_ops->asym_session_clear(dev, sess);
> > >
> > > + if (((struct rte_cryptodev_asym_session *)sess)->event_mdata)
> > > + rte_free(((struct rte_cryptodev_asym_session *
RE: [PATCH v3 6/7] test/event: add asymmetric cases for crypto adapter
> -Original Message-
> From: Akhil Goyal
> Sent: Friday, April 29, 2022 5:53 PM
> To: Gujjar, Abhinandan S ; dev@dpdk.org
> Cc: Anoob Joseph ; Jerin Jacob Kollanukkaran
> ; Jayatheerthan, Jay ;
> Vangati, Narender ; Volodymyr Fialko
>
> Subject: RE: [PATCH v3 6/7] test/event: add asymmetric cases for crypto
> adapter
>
> Hi Abhinandan,
>
> > This is failing with asym changes. Please look into this.
>
> Thanks for pointing this out. It is failing as null crypto does not support
> asym
> And asym_session_create would need an op from driver which is NULL for null
> crypto
>
> Please check if below change is working for you.
I could not apply this patch cleanly. I see that you are skipping the asym test
for NULL PMD.
Can I use openssl or any open source PMD to test this feature? If yes, please
provide the command line.
>
> diff --git a/app/test/test_event_crypto_adapter.c
> b/app/test/test_event_crypto_adapter.c
> index eecfc22057..2ecc7e2cea 100644
> --- a/app/test/test_event_crypto_adapter.c
> +++ b/app/test/test_event_crypto_adapter.c
> @@ -934,13 +934,16 @@ test_asym_session_with_op_new_mode(void)
> static int
> configure_cryptodev(void)
> {
> + const struct rte_cryptodev_capabilities *capability;
> struct rte_cryptodev_qp_conf qp_conf;
> struct rte_cryptodev_config conf;
> struct rte_cryptodev_info info;
> unsigned int session_size;
> + unsigned int i = 0;
> uint8_t nb_devs;
> int ret;
>
> +
> params.mbuf_pool = rte_pktmbuf_pool_create(
> "CRYPTO_ADAPTER_MBUFPOOL",
> NUM_MBUFS, MBUF_CACHE_SIZE, 0, MBUF_SIZE, @@ -963,19
> +966,6 @@ configure_cryptodev(void)
> RTE_LOG(ERR, USER1, "Can't create CRYPTO_OP_POOL\n");
> return TEST_FAILED;
> }
> - params.asym_op_mpool = rte_crypto_op_pool_create(
> - "EVENT_CRYPTO_ASYM_OP_POOL",
> - RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
> - NUM_MBUFS, MBUF_CACHE_SIZE,
> - (DEFAULT_NUM_XFORMS *
> - sizeof(struct rte_crypto_asym_xform)) +
> - sizeof(union rte_event_crypto_metadata),
> - rte_socket_id());
> - if (params.asym_op_mpool == NULL) {
> - RTE_LOG(ERR, USER1, "Can't create CRYPTO_ASYM_OP_POOL\n");
> - return TEST_FAILED;
> - }
> -
>
> /* Create a NULL crypto device */
> nb_devs = rte_cryptodev_device_count_by_driver(
> @@ -1020,16 +1010,34 @@ configure_cryptodev(void)
> TEST_ASSERT_NOT_NULL(params.session_priv_mpool,
> "session mempool allocation failed\n");
>
> - params.asym_sess_mpool = rte_cryptodev_asym_session_pool_create(
> - "CRYPTO_AD_ASYM_SESS_MP",
> - MAX_NB_SESSIONS, 0,
> - sizeof(union rte_event_crypto_metadata),
> - SOCKET_ID_ANY);
> - TEST_ASSERT_NOT_NULL(params.asym_sess_mpool,
> - "asym session mempool allocation failed\n");
> -
> -
> rte_cryptodev_info_get(TEST_CDEV_ID, &info);
> +
> + while ((capability = &info.capabilities[i++])->op !=
> + RTE_CRYPTO_OP_TYPE_UNDEFINED) {
> + if (capability->op == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
> + params.asym_op_mpool = rte_crypto_op_pool_create(
> + "EVENT_CRYPTO_ASYM_OP_POOL",
> + RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
> + NUM_MBUFS, MBUF_CACHE_SIZE,
> + (DEFAULT_NUM_XFORMS *
> + sizeof(struct rte_crypto_asym_xform)) +
> + sizeof(union rte_event_crypto_metadata),
> + rte_socket_id());
> + TEST_ASSERT_NOT_NULL(params.asym_op_mpool,
> + "Can't create
> + CRYPTO_ASYM_OP_POOL\n");
> +
> + params.asym_sess_mpool =
> + rte_cryptodev_asym_session_pool_create(
> + "CRYPTO_AD_ASYM_SESS_MP",
> + MAX_NB_SESSIONS, 0,
> + sizeof(union
> rte_event_crypto_metadata),
> + SOCKET_ID_ANY);
> + TEST_ASSERT_NOT_NULL(params.asym_sess_mpool,
> + "asym session mempool allocation failed\n");
> + break;
> + }
> + }
> +
> conf.nb_queue_pairs = info.max_nb_queue_pairs;
> conf.socket_id = SOCKET_ID_ANY;
> conf.ff_disable = RTE_CRYPTODEV_FF_SECURITY;
>
>
> >
> > root@xdp-dev:/home/intel/abhi/dpdk-next-eventdev/abhi#
> > ./app/test/dpdk- test
> > EAL: Detected CPU l
Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper
On Tue, Apr 26, 2022 at 8:12 AM Spike Du wrote: > > Hi Jerin, Hi Spike, > Thanks for your comments and sorry for the late response. > > For case one, I think I can refine the design and add LWM(limit > watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. OK. > > For case two(host shaper), I think we can't use RX meter, because > it's actually TX shaper on a remote system. It's quite specific to > Mellanox/Nvidia BlueField 2(BF2 for short) NIC. The NIC contains an ARM > system. We have two terms here: Host-system stands for the system the BF2 NIC > is inserted; ARM-system stands for the embedded ARM in BF2. ARM-system is > doing the forwarding. This is the way host shaper works: we configure the > register on ARM-system, but it affects Host-system's TX shaper, which means > the shaper is working on the remote port, it's not a RX meter concept, hence > we can't use DPDK RX meter framework. I'd suggest to still use private API. OK. If the host is using the DPDK application then rte_tm can be used on the egress side to enable the same. If it is not DPDK, then yes, we need private APIs. > > For testpmd part, I understand your concern. Because we need one > private API for host shaper, and we need testpmd's forwarding code to show > how it works to user, we need to call the private API in testpmd. If current > patch is not acceptable, what's the correct way to do it? Any framework to > isolate the PMD private logic from testpmd common code, but still give a > chance to call private APIs in testpmd? Please check "PMD API" item in http://mails.dpdk.org/archives/dev/2022-April/239191.html > > > Regards, > Spike. > > > > > -Original Message- > > From: Jerin Jacob > > Sent: Tuesday, April 5, 2022 4:59 PM > > To: Spike Du ; Andrew Rybchenko > > ; Cristian Dumitrescu > > ; Ferruh Yigit ; > > techbo...@dpdk.org > > Cc: Matan Azrad ; Slava Ovsiienko > > ; Ori Kam ; NBU-Contact- > > Thomas Monjalon (EXTERNAL) ; dpdk-dev > > ; Raslan Darawsheh > > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > > > External email: Use caution opening links or attachments > > > > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du wrote: > > > > > > LWM(limit watermark) is per RX queue attribute, when RX queue fullness > > > reach the LWM limit, HW sends an event to dpdk application. > > > Host shaper can configure shaper rate and lwm-triggered for a host port. > > > The shaper limits the rate of traffic from host port to wire port. > > > If lwm-triggered is enabled, a 100Mbps shaper is enabled automatically > > > when one of the host port's Rx queues receives LWM event. > > > > > > These two features can combine to control traffic from host port to wire > > port. > > > The work flow is configure LWM to RX queue and enable lwm-triggered > > > flag in host shaper, after receiving LWM event, delay a while until RX > > > queue is empty , then disable the shaper. We recycle this work flow to > > reduce RX queue drops. > > > > > > Spike Du (6): > > > net/mlx5: add LWM support for Rxq > > > common/mlx5: share interrupt management > > > net/mlx5: add LWM event handling support > > > net/mlx5: add private API to configure Rxq LWM > > > net/mlx5: add private API to config host port shaper > > > app/testpmd: add LWM and Host Shaper command > > > > + @Andrew Rybchenko @Ferruh Yigit cristian.dumitre...@intel.com > > > > I think, case one, can be easily abstracted via adding new > > rte_eth_event_type event and case two can be abstracted via the existing > > Rx meter framework in ethdev. > > > > Also, Updating generic testpmd to support PMD specific API should be > > avoided, I know there is existing stuff in testpmd, I think, we should have > > the > > policy to add PMD specific commands to testpmd. > > > > There are around 56PMDs in ethdev now, If PMDs try to add PMD specific > > API in testpmd it will be bloated or at minimum, it should a separate file > > in > > testpmd if we choose to take that path. > > > > + @techbo...@dpdk.org
Re: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
On Tue, Apr 26, 2022 at 3:49 PM Ray Kinsella wrote:
>
>
> jer...@marvell.com writes:
>
> > From: Jerin Jacob
> >
> > Currently, meter object supports only DSCP based on input color table,
> > The patch enhance that to support VLAN based input color table,
> > color table based on inner field for the tunnel use case, and
> > support for fallback color per meter if packet based on a different field.
> >
> > All of the above features are exposed through capability and added
> > additional capability to specify the implementation supports
> > more than one input color table per ethdev port.
> >
> > Suggested-by: Cristian Dumitrescu
> > Signed-off-by: Jerin Jacob
> > ---
> > v4..v3:
> >
> > - Aligned with community meeting call which is documented in
> > https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-sk...@marvell.com/
> > as last message. With following exception,
> > - Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as
> > there is already dscp_table and rte_mtr_meter_dscp_table_update() API.
> > Changing above symbols break existing application for no good.
> > - Updated 22.07 release notes
> > - Remove testpmd changes from series to finalize the API spec first and
> > then we can send testpmd changes.
> >
> > v3..v2:
> >
> > - Fix input color flags as a bitmask
> > - Add definitions for newly added API
> >
> > v2..v1:
> > - Fix seperate typo
> >
> > v1..RFC:
> >
> > Address the review comments by Cristian at
> > https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jer...@marvell.com/
> >
> > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> > index 20391ab29e..cccbf6dee5 100644
> > --- a/lib/ethdev/version.map
> > +++ b/lib/ethdev/version.map
> > @@ -279,6 +279,10 @@ EXPERIMENTAL {
> > rte_flow_async_action_handle_create;
> > rte_flow_async_action_handle_destroy;
> > rte_flow_async_action_handle_update;
> > +
> > + # added in 22.07
>
> Symbols are not in alphabetical order.
Thanks. Will fix it in v5
>
> > + rte_mtr_meter_vlan_table_update;
> > + rte_mtr_color_in_protocol_priority_set;
> > };
> >
> > INTERNAL {
>
>
> --
> Regards, Ray K
Re: [dpdk-dev] [PATCH v4] ethdev: mtr: support protocol based input color selection
On Tue, Apr 26, 2022 at 5:38 PM Dumitrescu, Cristian
wrote:
>
> Hi Jerin,
Hi Cristian
>
> Thank you for implementing according to our agreement, I am happy to see that
> we are converging.
:-)
>
> Here are some comments below:
>
>
>
> > diff --git a/lib/ethdev/rte_mtr.h b/lib/ethdev/rte_mtr.h
> > index 40df0888c8..76ffbcf724 100644
> > --- a/lib/ethdev/rte_mtr.h
> > +++ b/lib/ethdev/rte_mtr.h
> > @@ -213,6 +213,52 @@ struct rte_mtr_meter_policy_params {
> > const struct rte_flow_action *actions[RTE_COLORS];
> > };
> >
> > +/**
> > + * Input color protocol method
>
> I suggest adding some more explanations here:
> More than one method can be enabled for a given meter. Even if enabled, a
> method might not be applicable to each input packet, in case the associated
> protocol header is not present in the packet. The highest priority method
> that is both enabled for the meter and also applicable for the current input
> packet wins; if none is both enabled and applicable, the default input color
> is used. @see function rte_mtr_color_in_protocol_priority_set()
OK.
>
> > + */
> > +enum rte_mtr_color_in_protocol {
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the outermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
>
> The statement "Otherwise, the *default_input_color* is applied" is incorrect
> IMO and should be removed, as multiple methods might be enabled and also
> applicable to a specific input packet, in which case the highest priority
> method wins, as opposed to the default input color.
>
> I suggest a simplification "Enable the detection of the packet input color
> based on the outermost VLAN header fields DEI (1 bit) and PCP (3 bits). These
> fields are used as index into the VLAN table"
OK
>
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
> > + RTE_MTR_COLOR_IN_PROTO_OUTER_VLAN = RTE_BIT64(0),
> > + /**
> > + * If the input packet has at least one VLAN label, its input color is
> > + * detected by the innermost VLAN DEI(1bit), PCP(3 bits)
> > + * indexing into the struct rte_mtr_params::vlan_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::vlan_table
> > + */
>
> Same simplification suggested here.
OK
>
> > + RTE_MTR_COLOR_IN_PROTO_INNER_VLAN = RTE_BIT64(1),
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the outermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
>
> Same simplification suggested here.
OK
>
> > + RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP = RTE_BIT64(2),
>
> I am OK to keep DSCP for the name of the table instead of renaming the table,
> as you suggested, but this method name should reflect the protocol, not the
> field: RTE_MTR_COLOR_IN_PROTO_OUTER_IP.
OK
>
> > + /**
> > + * If the input packet is IPv4 or IPv6, its input color is detected by
> > + * the innermost DSCP field indexing into the
> > + * struct rte_mtr_params::dscp_table.
> > + * Otherwise, the *default_input_color* is applied.
> > + *
> > + * @see struct rte_mtr_params::default_input_color
> > + * @see struct rte_mtr_params::dscp_table
> > + */
>
> Same simplification suggested here.
OK
>
> > + RTE_MTR_COLOR_IN_PROTO_INNER_DSCP = RTE_BIT64(3),
>
> I am OK to keep DSCP for the name of the table instead of renaming the table,
> as you suggested, but this method name should reflect the protocol, not the
> field: RTE_MTR_COLOR_IN_PROTO_INNER_IP.
OK
>
> > +
> > /**
> > * Parameters for each traffic metering & policing object
> > *
> > @@ -233,20 +279,58 @@ struct rte_mtr_params {
> >*/
> > int use_prev_mtr_color;
> >
> > - /** Meter input color. When non-NULL: it points to a pre-allocated and
> > + /** Meter input color based on IP DSCP protocol field.
> > + *
> > + * Valid when *input_color_proto_mask* set to any of the following
> > + * RTE_MTR_COLOR_IN_PROTO_OUTER_DSCP,
> > + * RTE_MTR_COLOR_IN_PROTO_INNER_DSCP
> > + *
> > + * When non-NULL: it points to a pre-allocated and
> >* pre-populated table with exactly 64 elements providing the input
> >* color for each value of the IPv4/IPv6 Differentiated Services Code
> > - * Point (DSCP) input packet field. When NULL: it is equivalent to
> > - * setting this parameter to an all-green po
RE: [PATCH v3 7/7] test-eventdev: support asym ops for crypto adapter
Acked-by: Abhinandan Gujjar
> -Original Message-
> From: Akhil Goyal
> Sent: Thursday, April 21, 2022 8:07 PM
> To: dev@dpdk.org
> Cc: ano...@marvell.com; jer...@marvell.com; Gujjar, Abhinandan S
> ; Jayatheerthan, Jay
> ; Vangati, Narender
> ; vfia...@marvell.com; Akhil Goyal
>
> Subject: [PATCH v3 7/7] test-eventdev: support asym ops for crypto adapter
>
> Test eventdev app is updated to add new option for asymmetric crypto ops for
> event crypto adapter.
>
> Signed-off-by: Akhil Goyal
> ---
> app/test-eventdev/evt_common.h | 2 +
> app/test-eventdev/evt_options.c | 17 ++
> app/test-eventdev/evt_options.h | 4 +
> app/test-eventdev/test_perf_atq.c| 12 +-
> app/test-eventdev/test_perf_common.c | 250 +++
> app/test-eventdev/test_perf_common.h | 45 +++-- app/test-
> eventdev/test_perf_queue.c | 12 +-
> doc/guides/tools/testeventdev.rst| 5 +
> 8 files changed, 284 insertions(+), 63 deletions(-)
>
> diff --git a/app/test-eventdev/evt_common.h b/app/test-
> eventdev/evt_common.h index 2f301a7e79..196eca8bd0 100644
> --- a/app/test-eventdev/evt_common.h
> +++ b/app/test-eventdev/evt_common.h
> @@ -6,6 +6,7 @@
> #define _EVT_COMMON_
>
> #include
> +#include
> #include
> #include
> #include
> @@ -80,6 +81,7 @@ struct evt_options {
> uint64_t optm_timer_tick_nsec;
> enum evt_prod_type prod_type;
> enum rte_event_crypto_adapter_mode crypto_adptr_mode;
> + enum rte_crypto_op_type crypto_op_type;
> };
>
> static inline bool
> diff --git a/app/test-eventdev/evt_options.c b/app/test-eventdev/evt_options.c
> index d3c704d2b3..8326734b64 100644
> --- a/app/test-eventdev/evt_options.c
> +++ b/app/test-eventdev/evt_options.c
> @@ -38,6 +38,7 @@ evt_options_default(struct evt_options *opt)
> opt->eth_queues = 1;
> opt->vector_size = 64;
> opt->vector_tmo_nsec = 100E3;
> + opt->crypto_op_type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
> }
>
> typedef int (*option_parser_t)(struct evt_options *opt, @@ -142,6 +143,18
> @@ evt_parse_crypto_adptr_mode(struct evt_options *opt, const char *arg)
> return ret;
> }
>
> +static int
> +evt_parse_crypto_op_type(struct evt_options *opt, const char *arg) {
> + uint8_t op_type;
> + int ret;
> +
> + ret = parser_read_uint8(&op_type, arg);
> + opt->crypto_op_type = op_type ?
> RTE_CRYPTO_OP_TYPE_ASYMMETRIC :
> + RTE_CRYPTO_OP_TYPE_SYMMETRIC;
> + return ret;
> +}
> +
> static int
> evt_parse_test_name(struct evt_options *opt, const char *arg) { @@ -368,6
> +381,8 @@ usage(char *program)
> "\t--expiry_nsec : event timer expiry ns.\n"
> "\t--crypto_adptr_mode : 0 for OP_NEW mode (default)
> and\n"
> "\t 1 for OP_FORWARD mode.\n"
> + "\t--crypto_op_type : 0 for SYM ops (default) and\n"
> + "\t 1 for ASYM ops.\n"
> "\t--mbuf_sz : packet mbuf size.\n"
> "\t--max_pkt_sz : max packet size.\n"
> "\t--prod_enq_burst_sz : producer enqueue burst size.\n"
> @@ -442,6 +457,7 @@ static struct option lgopts[] = {
> { EVT_PROD_TIMERDEV, 0, 0, 0 },
> { EVT_PROD_TIMERDEV_BURST, 0, 0, 0 },
> { EVT_CRYPTO_ADPTR_MODE, 1, 0, 0 },
> + { EVT_CRYPTO_OP_TYPE, 1, 0, 0 },
> { EVT_NB_TIMERS, 1, 0, 0 },
> { EVT_NB_TIMER_ADPTRS, 1, 0, 0 },
> { EVT_TIMER_TICK_NSEC, 1, 0, 0 },
> @@ -484,6 +500,7 @@ evt_opts_parse_long(int opt_idx, struct evt_options
> *opt)
> { EVT_PROD_TIMERDEV, evt_parse_timer_prod_type},
> { EVT_PROD_TIMERDEV_BURST,
> evt_parse_timer_prod_type_burst},
> { EVT_CRYPTO_ADPTR_MODE, evt_parse_crypto_adptr_mode},
> + { EVT_CRYPTO_OP_TYPE, evt_parse_crypto_op_type},
> { EVT_NB_TIMERS, evt_parse_nb_timers},
> { EVT_NB_TIMER_ADPTRS, evt_parse_nb_timer_adptrs},
> { EVT_TIMER_TICK_NSEC, evt_parse_timer_tick_nsec}, diff --git
> a/app/test-eventdev/evt_options.h b/app/test-eventdev/evt_options.h index
> 2231c58801..f23fb8a511 100644
> --- a/app/test-eventdev/evt_options.h
> +++ b/app/test-eventdev/evt_options.h
> @@ -38,6 +38,7 @@
> #define EVT_PROD_TIMERDEV("prod_type_timerdev")
> #define EVT_PROD_TIMERDEV_BURST ("prod_type_timerdev_burst")
> #define EVT_CRYPTO_ADPTR_MODE ("crypto_adptr_mode")
> +#define EVT_CRYPTO_OP_TYPE("crypto_op_type")
> #define EVT_NB_TIMERS("nb_timers")
> #define EVT_NB_TIMER_ADPTRS ("nb_timer_adptrs")
> #define EVT_TIMER_TICK_NSEC ("timer_tick_nsec")
> @@ -298,6 +299,9 @@ evt_dump_producer_type(struct evt_options *opt)
>"Event crypto adapter producers");
> evt_dump("crypto adapter mode", "%s",
>opt->crypto_adptr_mode ? "OP_FORWARD" :
> "OP_NEW");
> +
RE: [PATCH v3 2/7] crypto/cnxk: add event metadata set operation
Acked-by: Abhinandan Gujjar
Minor comment below
> -Original Message-
> From: Akhil Goyal
> Sent: Thursday, April 21, 2022 8:07 PM
> To: dev@dpdk.org
> Cc: ano...@marvell.com; jer...@marvell.com; Gujjar, Abhinandan S
> ; Jayatheerthan, Jay
> ; Vangati, Narender
> ; vfia...@marvell.com; Akhil Goyal
>
> Subject: [PATCH v3 2/7] crypto/cnxk: add event metadata set operation
>
> From: Volodymyr Fialko
>
> Added cryptodev operation for setting event crypto metadata for all supported
> sessions - sym/asym/security.
>
> Signed-off-by: Volodymyr Fialko
> Signed-off-by: Akhil Goyal
> ---
> drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++---
> drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
> drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 ++---
> drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
> drivers/crypto/cnxk/cnxk_ae.h | 2 +
> drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 ---
> drivers/crypto/cnxk/cnxk_se.h | 2 +
> 7 files changed, 255 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
> b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
> index c4d5d039ec..01aa0d6870 100644
> --- a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
> +++ b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
> @@ -264,30 +264,136 @@ cn10k_cpt_enqueue_burst(void *qptr, struct
> rte_crypto_op **ops, uint16_t nb_ops)
> return count + i;
> }
>
> -uint16_t
> -cn10k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct rte_crypto_op
> *op)
> +static int
> +cn10k_cpt_crypto_adapter_ev_mdata_set(struct rte_cryptodev *dev
> __rte_unused,
> + void *sess,
> + enum rte_crypto_op_type op_type,
> + enum rte_crypto_op_sess_type sess_type,
> + void *mdata)
> {
> - union rte_event_crypto_metadata *ec_mdata;
> - struct cpt_inflight_req *infl_req;
> + union rte_event_crypto_metadata *ec_mdata = mdata;
> struct rte_event *rsp_info;
> - uint64_t lmt_base, lmt_arg;
> - struct cpt_inst_s *inst;
> struct cnxk_cpt_qp *qp;
> uint8_t cdev_id;
> - uint16_t lmt_id;
> - uint16_t qp_id;
> - int ret;
> -
> - ec_mdata = cnxk_event_crypto_mdata_get(op);
> - if (!ec_mdata) {
> - rte_errno = EINVAL;
> - return 0;
> - }
> + int16_t qp_id;
> + uint64_t w2;
>
> + /* Get queue pair */
> cdev_id = ec_mdata->request_info.cdev_id;
> qp_id = ec_mdata->request_info.queue_pair_id;
> qp = rte_cryptodevs[cdev_id].data->queue_pairs[qp_id];
> +
> + /* Prepare w2 */
> rsp_info = &ec_mdata->response_info;
> + w2 = CNXK_CPT_INST_W2(
> + (RTE_EVENT_TYPE_CRYPTODEV << 28) | rsp_info->flow_id,
> + rsp_info->sched_type, rsp_info->queue_id, 0);
> +
> + /* Set meta according to session type */
> + if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
> + if (sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
> + struct cn10k_sec_session *priv;
> + struct cn10k_ipsec_sa *sa;
> +
> + priv = get_sec_session_private_data(sess);
> + sa = &priv->sa;
> + sa->qp = qp;
> + sa->inst.w2 = w2;
> + } else if (sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> + struct cnxk_se_sess *priv;
> +
> + priv = get_sym_session_private_data(
> + sess, cn10k_cryptodev_driver_id);
> + priv->qp = qp;
> + priv->cpt_inst_w2 = w2;
> + } else
cnXX_ca_meta_info_extract() supports SESSIONLESS case. But no support here.
Is this expected?
> + return -EINVAL;
> + } else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
> + if (sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> + struct rte_cryptodev_asym_session *asym_sess = sess;
> + struct cnxk_ae_sess *priv;
> +
> + priv = (struct cnxk_ae_sess *)asym_sess-
> >sess_private_data;
> + priv->qp = qp;
> + priv->cpt_inst_w2 = w2;
> + } else
> + return -EINVAL;
> + } else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static inline int
> +cn10k_ca_meta_info_extract(struct rte_crypto_op *op,
> + struct cnxk_cpt_qp **qp, uint64_t *w2) {
> + if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
> + if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
> + struct cn10k_sec_session *priv;
> + struct cn10k_ipsec_sa *sa;
> +
> + priv = get_sec_session_private_data(op->sym-
> >sec_session);
> + sa = &priv->sa;
> + *qp = sa-
RE: [PATCH v3 3/7] crypto/octeontx: use new API for event metadata
Acked-by: Abhinandan Gujjar
> -Original Message-
> From: Akhil Goyal
> Sent: Thursday, April 21, 2022 8:07 PM
> To: dev@dpdk.org
> Cc: ano...@marvell.com; jer...@marvell.com; Gujjar, Abhinandan S
> ; Jayatheerthan, Jay
> ; Vangati, Narender
> ; vfia...@marvell.com; Akhil Goyal
>
> Subject: [PATCH v3 3/7] crypto/octeontx: use new API for event metadata
>
> For getting event crypto metadata from crypto_op, the new API
> rte_cryptodev_get_session_event_mdata can be used directly instead of
> getting userdata inside PMD.
>
> Signed-off-by: Akhil Goyal
> ---
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +---
> 1 file changed, 1 insertion(+), 19 deletions(-)
>
> diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> index ddb1266c3c..d5851d9987 100644
> --- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> +++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> @@ -684,24 +684,6 @@ submit_request_to_sso(struct ssows *ws, uintptr_t
> req,
> ssovf_store_pair(add_work, req, ws->grps[rsp_info->queue_id]); }
>
> -static inline union rte_event_crypto_metadata * -
> get_event_crypto_mdata(struct rte_crypto_op *op) -{
> - union rte_event_crypto_metadata *ec_mdata;
> -
> - if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
> - ec_mdata = rte_cryptodev_sym_session_get_user_data(
> -op->sym->session);
> - else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
> - op->private_data_offset)
> - ec_mdata = (union rte_event_crypto_metadata *)
> - ((uint8_t *)op + op->private_data_offset);
> - else
> - return NULL;
> -
> - return ec_mdata;
> -}
> -
> uint16_t __rte_hot
> otx_crypto_adapter_enqueue(void *port, struct rte_crypto_op *op) { @@ -
> 712,7 +694,7 @@ otx_crypto_adapter_enqueue(void *port, struct
> rte_crypto_op *op)
> uint8_t op_type, cdev_id;
> uint16_t qp_id;
>
> - ec_mdata = get_event_crypto_mdata(op);
> + ec_mdata = rte_cryptodev_session_event_mdata_get(op);
> if (unlikely(ec_mdata == NULL)) {
> rte_errno = EINVAL;
> return 0;
> --
> 2.25.1
Re: [PATCH 1/4] common/cnxk: add CN103XX platform support
On Fri, Mar 25, 2022 at 6:34 PM Rahul Bhansali wrote:
>
> Added support for CN103XX (cn10kb) platform.
Since 2/4. 3/4, 4/4 patches do not have any special description.
Please squash all patches and send v2.
It can go through the main tree as it touches all driver's PCI ID values.
>
> Signed-off-by: Rahul Bhansali
> ---
> doc/guides/platform/cnxk.rst| 1 +
> drivers/common/cnxk/roc_constants.h | 1 +
> drivers/common/cnxk/roc_model.c | 4
> drivers/common/cnxk/roc_model.h | 11 ++-
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/platform/cnxk.rst b/doc/guides/platform/cnxk.rst
> index 3dee725ac5..92aa702a78 100644
> --- a/doc/guides/platform/cnxk.rst
> +++ b/doc/guides/platform/cnxk.rst
> @@ -18,6 +18,7 @@ Supported OCTEON cnxk SoCs
> - CN98xx
> - CN106xx
> - CNF105xx
> +- CN103XX
>
> Resource Virtualization Unit architecture
> -
> diff --git a/drivers/common/cnxk/roc_constants.h
> b/drivers/common/cnxk/roc_constants.h
> index 38e2087a26..1daaabfe55 100644
> --- a/drivers/common/cnxk/roc_constants.h
> +++ b/drivers/common/cnxk/roc_constants.h
> @@ -52,6 +52,7 @@
> #define PCI_SUBSYSTEM_DEVID_CN10KA 0xB900
> #define PCI_SUBSYSTEM_DEVID_CN10KAS 0xB900
> #define PCI_SUBSYSTEM_DEVID_CNF10KA 0xBA00
> +#define PCI_SUBSYSTEM_DEVID_CN10KB 0xB900
>
> #define PCI_SUBSYSTEM_DEVID_CN9KA 0x
> #define PCI_SUBSYSTEM_DEVID_CN9KB 0xb400
> diff --git a/drivers/common/cnxk/roc_model.c b/drivers/common/cnxk/roc_model.c
> index 4120029541..1dd374e0fd 100644
> --- a/drivers/common/cnxk/roc_model.c
> +++ b/drivers/common/cnxk/roc_model.c
> @@ -16,6 +16,7 @@ struct roc_model *roc_model;
> #define PART_106xx 0xB9
> #define PART_105xx 0xBA
> #define PART_105xxN 0xBC
> +#define PART_103xx 0xBE
> #define PART_98xx 0xB1
> #define PART_96xx 0xB2
> #define PART_95xx 0xB3
> @@ -46,6 +47,7 @@ static const struct model_db {
> } model_db[] = {
> {VENDOR_ARM, PART_106xx, 0, 0, ROC_MODEL_CN106xx_A0, "cn10ka_a0"},
> {VENDOR_ARM, PART_105xx, 0, 0, ROC_MODEL_CNF105xx_A0, "cnf10ka_a0"},
> + {VENDOR_ARM, PART_103xx, 0, 0, ROC_MODEL_CN103xx_A0, "cn10kb_a0"},
> {VENDOR_ARM, PART_105xxN, 0, 0, ROC_MODEL_CNF105xxN_A0, "cnf10kb_a0"},
> {VENDOR_CAVIUM, PART_98xx, 0, 0, ROC_MODEL_CN98xx_A0, "cn98xx_a0"},
> {VENDOR_CAVIUM, PART_96xx, 0, 0, ROC_MODEL_CN96xx_A0, "cn96xx_a0"},
> @@ -92,6 +94,8 @@ cn10k_part_get(void)
> soc = PART_105xx;
> } else if (strcmp("cnf10kb", ptr) == 0) {
> soc = PART_105xxN;
> + } else if (strcmp("cn10kb", ptr) == 0) {
> + soc = PART_103xx;
> } else {
> plt_err("Unidentified 'CPU compatible': <%s>", ptr);
> goto fclose;
> diff --git a/drivers/common/cnxk/roc_model.h b/drivers/common/cnxk/roc_model.h
> index 4567566169..885c3d668f 100644
> --- a/drivers/common/cnxk/roc_model.h
> +++ b/drivers/common/cnxk/roc_model.h
> @@ -24,6 +24,7 @@ struct roc_model {
> #define ROC_MODEL_CN106xx_A0 BIT_ULL(20)
> #define ROC_MODEL_CNF105xx_A0 BIT_ULL(21)
> #define ROC_MODEL_CNF105xxN_A0 BIT_ULL(22)
> +#define ROC_MODEL_CN103xx_A0 BIT_ULL(23)
> /* Following flags describe platform code is running on */
> #define ROC_ENV_HW BIT_ULL(61)
> #define ROC_ENV_EMUL BIT_ULL(62)
> @@ -50,8 +51,10 @@ struct roc_model {
> #define ROC_MODEL_CN106xx (ROC_MODEL_CN106xx_A0)
> #define ROC_MODEL_CNF105xx (ROC_MODEL_CNF105xx_A0)
> #define ROC_MODEL_CNF105xxN (ROC_MODEL_CNF105xxN_A0)
> +#define ROC_MODEL_CN103xx (ROC_MODEL_CN103xx_A0)
> #define ROC_MODEL_CN10K
> \
> - (ROC_MODEL_CN106xx | ROC_MODEL_CNF105xx | ROC_MODEL_CNF105xxN)
> + (ROC_MODEL_CN106xx | ROC_MODEL_CNF105xx | ROC_MODEL_CNF105xxN |
> \
> +ROC_MODEL_CN103xx)
> #define ROC_MODEL_CNF10K (ROC_MODEL_CNF105xx | ROC_MODEL_CNF105xxN)
>
> /* Runtime variants */
> @@ -152,6 +155,12 @@ roc_model_is_cnf10kb(void)
> return roc_model->flag & ROC_MODEL_CNF105xxN;
> }
>
> +static inline uint64_t
> +roc_model_is_cn10kb_a0(void)
> +{
> + return roc_model->flag & ROC_MODEL_CN103xx_A0;
> +}
> +
> static inline uint64_t
> roc_model_is_cn10ka_a0(void)
> {
> --
> 2.25.1
>
Re: [PATCH v4] eal: add seqlock
On 2022-04-28 12:28, David Marchand wrote:
Hello Mattias,
On Fri, Apr 8, 2022 at 4:25 PM Mattias Rönnblom
wrote:
A sequence lock (seqlock) is synchronization primitive which allows
for data-race free, low-overhead, high-frequency reads, especially for
data structures shared across many cores and which are updated
relatively infrequently.
A seqlock permits multiple parallel readers. The variant of seqlock
implemented in this patch supports multiple writers as well. A
spinlock is used for writer-writer serialization.
To avoid resource reclamation and other issues, the data protected by
a seqlock is best off being self-contained (i.e., no pointers [except
to constant data]).
One way to think about seqlocks is that they provide means to perform
atomic operations on data objects larger what the native atomic
machine instructions allow for.
DPDK seqlocks are not preemption safe on the writer side. A thread
preemption affects performance, not correctness.
A seqlock contains a sequence number, which can be thought of as the
generation of the data it protects.
A reader will
1. Load the sequence number (sn).
2. Load, in arbitrary order, the seqlock-protected data.
3. Load the sn again.
4. Check if the first and second sn are equal, and even numbered.
If they are not, discard the loaded data, and restart from 1.
The first three steps need to be ordered using suitable memory fences.
A writer will
1. Take the spinlock, to serialize writer access.
2. Load the sn.
3. Store the original sn + 1 as the new sn.
4. Perform load and stores to the seqlock-protected data.
5. Store the original sn + 2 as the new sn.
6. Release the spinlock.
Proper memory fencing is required to make sure the first sn store, the
data stores, and the second sn store appear to the reader in the
mentioned order.
The sn loads and stores must be atomic, but the data loads and stores
need not be.
The original seqlock design and implementation was done by Stephen
Hemminger. This is an independent implementation, using C11 atomics.
For more information on seqlocks, see
https://en.wikipedia.org/wiki/Seqlock
Revisions changelog should be after commitlog, separated with ---.
OK.
PATCH v4:
* Reverted to Linux kernel style naming on the read side.
* Bail out early from the retry function if an odd sequence
number is encountered.
* Added experimental warnings in the API documentation.
* Static initializer now uses named field initialization.
* Various tweaks to API documentation (including the example).
PATCH v3:
* Renamed both read and write-side critical section begin/end functions
to better match rwlock naming, per Ola Liljedahl's suggestion.
* Added 'extern "C"' guards for C++ compatibility.
* Refer to the main lcore as the main lcore, and nothing else.
PATCH v2:
* Skip instead of fail unit test in case too few lcores are available.
* Use main lcore for testing, reducing the minimum number of lcores
required to run the unit tests to four.
* Consistently refer to sn field as the "sequence number" in the
documentation.
* Fixed spelling mistakes in documentation.
Updates since RFC:
* Added API documentation.
* Added link to Wikipedia article in the commit message.
* Changed seqlock sequence number field from uint64_t (which was
overkill) to uint32_t. The sn type needs to be sufficiently large
to assure no reader will read a sn, access the data, and then read
the same sn, but the sn has been incremented enough times to have
wrapped during the read, and arrived back at the original sn.
* Added RTE_SEQLOCK_INITIALIZER macro for static initialization.
* Removed the rte_seqlock struct + separate rte_seqlock_t typedef
with an anonymous struct typedef:ed to rte_seqlock_t.
Acked-by: Morten Brørup
Reviewed-by: Ola Liljedahl
Signed-off-by: Mattias Rönnblom
We are missing a MAINTAINERS update, either with a new section for
this lock (like for MCS and ticket locks), or adding the new test code
under the EAL API and common code section (like rest of the locks).
OK. I added a new section, and myself as the maintainer. If you want to
merge it with EAL and the common code that fine with me as well. Let me
know in that case. The seqlock is a tiny bit of code, but there are some
intricacies (like always when C11 memory models matter).
This new lock is not referenced in doxygen (see doc/api/doxy-api-index.md).
OK.
It's worth a release notes update for advertising this new lock type.
OK.
[snip]
diff --git a/app/test/test_seqlock.c b/app/test/test_seqlock.c
new file mode 100644
index 00..3f1ce53678
--- /dev/null
+++ b/app/test/test_seqlock.c
[snip]
+/* Only a compile-time test */
+static rte_seqlock_t __rte_unused static_init_lock = RTE_SEQLOCK_INITIALIZER;
+
+static int
+test_seqlock(void)
+{
+ struct reader readers[MAX_READERS];
+ unsigned int num_readers;
+ unsign
[PATCH v5] eal: add seqlock
A sequence lock (seqlock) is synchronization primitive which allows for data-race free, low-overhead, high-frequency reads, especially for data structures shared across many cores and which are updated relatively infrequently. A seqlock permits multiple parallel readers. The variant of seqlock implemented in this patch supports multiple writers as well. A spinlock is used for writer-writer serialization. To avoid resource reclamation and other issues, the data protected by a seqlock is best off being self-contained (i.e., no pointers [except to constant data]). One way to think about seqlocks is that they provide means to perform atomic operations on data objects larger than what the native atomic machine instructions allow for. DPDK seqlocks are not preemption safe on the writer side. A thread preemption affects performance, not correctness. A seqlock contains a sequence number, which can be thought of as the generation of the data it protects. A reader will 1. Load the sequence number (sn). 2. Load, in arbitrary order, the seqlock-protected data. 3. Load the sn again. 4. Check if the first and second sn are equal, and even numbered. If they are not, discard the loaded data, and restart from 1. The first three steps need to be ordered using suitable memory fences. A writer will 1. Take the spinlock, to serialize writer access. 2. Load the sn. 3. Store the original sn + 1 as the new sn. 4. Perform load and stores to the seqlock-protected data. 5. Store the original sn + 2 as the new sn. 6. Release the spinlock. Proper memory fencing is required to make sure the first sn store, the data stores, and the second sn store appear to the reader in the mentioned order. The sn loads and stores must be atomic, but the data loads and stores need not be. The original seqlock design and implementation was done by Stephen Hemminger. This is an independent implementation, using C11 atomics. For more information on seqlocks, see https://en.wikipedia.org/wiki/Seqlock --- PATCH v5: * Add sequence lock section to MAINTAINERS. * Add entry in the release notes. * Add seqlock reference in the API index. * Fix meson build file indentation. * Use "increment" to describe how a writer changes the sequence number. * Remove compiler barriers from seqlock test. * Use appropriate macros (e.g., TEST_SUCCESS) for test return values. PATCH v4: * Reverted to Linux kernel style naming on the read side. * Bail out early from the retry function if an odd sequence number is encountered. * Added experimental warnings in the API documentation. * Static initializer now uses named field initialization. * Various tweaks to API documentation (including the example). PATCH v3: * Renamed both read and write-side critical section begin/end functions to better match rwlock naming, per Ola Liljedahl's suggestion. * Added 'extern "C"' guards for C++ compatibility. * Refer to the main lcore as the main lcore, and nothing else. PATCH v2: * Skip instead of fail unit test in case too few lcores are available. * Use main lcore for testing, reducing the minimum number of lcores required to run the unit tests to four. * Consistently refer to sn field as the "sequence number" in the documentation. * Fixed spelling mistakes in documentation. Updates since RFC: * Added API documentation. * Added link to Wikipedia article in the commit message. * Changed seqlock sequence number field from uint64_t (which was overkill) to uint32_t. The sn type needs to be sufficiently large to assure no reader will read a sn, access the data, and then read the same sn, but the sn has been incremented enough times to have wrapped during the read, and arrived back at the original sn. * Added RTE_SEQLOCK_INITIALIZER macro for static initialization. * Removed the rte_seqlock struct + separate rte_seqlock_t typedef with an anonymous struct typedef:ed to rte_seqlock_t. Acked-by: Morten Brørup Acked-by: Konstantin Ananyev Reviewed-by: Ola Liljedahl Signed-off-by: Mattias Rönnblom --- MAINTAINERS| 5 + app/test/meson.build | 2 + app/test/test_seqlock.c| 183 ++ doc/api/doxy-api-index.md | 1 + doc/guides/rel_notes/release_22_07.rst | 14 ++ lib/eal/common/meson.build | 1 + lib/eal/common/rte_seqlock.c | 12 + lib/eal/include/meson.build| 1 + lib/eal/include/rte_seqlock.h | 322 + lib/eal/version.map| 3 + 10 files changed, 544 insertions(+) create mode 100644 app/test/test_seqlock.c create mode 100644 lib/eal/common/rte_seqlock.c create mode 100644 lib/eal/include/rte_seqlock.h diff --git a/MAINTAINERS b/MAINTAINERS index 7c4f541dba..2804d8136c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -262,6 +262,11 @@ M: Joyce Kong F: lib/eal/include/generic/rte_ticketlock.h F:
Re: [PATCH v5] eal: add seqlock
On 2022-05-01 16:03, Mattias Rönnblom wrote: A sequence lock (seqlock) is synchronization primitive which allows "/../ is a /../" David, maybe you can fix this typo? Unless there is a need for a new version.
[dpdk-dev] [PATCH v5] ethdev: mtr: support protocol based input color selection
From: Jerin Jacob Currently, meter object supports only DSCP based on input color table, The patch enhance that to support VLAN based input color table, color table based on inner field for the tunnel use case, and support for fallback color per meter if packet based on a different field. All of the above features are exposed through capability and added additional capability to specify the implementation supports more than one input color table per ethdev port. Suggested-by: Cristian Dumitrescu Signed-off-by: Jerin Jacob --- v5..v4: - Improved the Doxgen comments as per http://patches.dpdk.org/project/dpdk/patch/20220421180241.514767-1-jer...@marvell.com/ - Removed input_color_proto_mask - Renamed rte_mtr_color_in_protocol_priority_set() to rte_mtr_color_in_protocol_set() - Introduced rte_mtr_color_in_protocol_get(), rte_mtr_color_in_protocol_priority_get() for getting the configured input color protocol. v4..v3: - Aligned with community meeting call which is documented in https://patches.dpdk.org/project/dpdk/patch/20220301085824.1041009-1-sk...@marvell.com/ as last message. With following exception, - Used RTE_MTR_COLOR_IN_*_DSCP instead of RTE_MTR_COLOR_IN_*_IP as there is already dscp_table and rte_mtr_meter_dscp_table_update() API. Changing above symbols break existing application for no good. - Updated 22.07 release notes - Remove testpmd changes from series to finalize the API spec first and then we can send testpmd changes. v3..v2: - Fix input color flags as a bitmask - Add definitions for newly added API v2..v1: - Fix seperate typo v1..RFC: Address the review comments by Cristian at https://patches.dpdk.org/project/dpdk/patch/20210820082401.3778736-1-jer...@marvell.com/ .../traffic_metering_and_policing.rst | 35 +++ doc/guides/rel_notes/release_22_07.rst| 10 + lib/ethdev/rte_mtr.c | 50 lib/ethdev/rte_mtr.h | 216 +- lib/ethdev/rte_mtr_driver.h | 38 +++ lib/ethdev/version.map| 6 + 6 files changed, 345 insertions(+), 10 deletions(-) diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst index ceb5a96488..d1958a023d 100644 --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst @@ -21,6 +21,7 @@ The main features are: * Policer actions (per meter output color): recolor, drop * Statistics (per policer output color) * Chaining multiple meter objects +* Protocol based input color selection Configuration steps --- @@ -105,3 +106,37 @@ traffic meter and policing library. * Adding one (or multiple) actions of the type ``RTE_FLOW_ACTION_TYPE_METER`` to the list of meter actions (``struct rte_mtr_meter_policy_params::actions``) specified per color as show in :numref:`figure_rte_mtr_chaining`. + +Protocol based input color selection + + +The API supports selecting the input color based on the packet content. +Following is the API usage model for the same. + +#. Probe the protocol based input color selection device capabilities using + the following parameters with ``rte_mtr_capabilities_get()`` API. + + * ``struct rte_mtr_capabilities::input_color_proto_mask;`` + * ``struct rte_mtr_capabilities::separate_input_color_table_per_port`` + +#. When creating the meter object using ``rte_mtr_create()``, configure + relevant input color selection parameters such as + + * Fill the tables ``struct rte_mtr_params::dscp_table``, + ``struct rte_mtr_params::vlan_table`` based on input color selected. + + * Update the ``struct rte_mtr_params::default_input_color`` to determine + the default input color in case the input packet does not match + the input color method. + +#. Use the following APIs to configure the meter object + + * Select the input protocol color with ``rte_mtr_color_in_protocol_set()`` API. + + * If needed, update the input color table at runtime using + ``rte_mtr_meter_vlan_table_update()`` and ``rte_mtr_meter_dscp_table_update()`` + APIs. + + * Application can query the configured input color protocol and its associated + priority using ``rte_mtr_color_in_protocol_get()`` and + ``rte_mtr_color_in_protocol_priority_get()`` APIs. diff --git a/doc/guides/rel_notes/release_22_07.rst b/doc/guides/rel_notes/release_22_07.rst index 88d6e96cc1..74ecc3f53d 100644 --- a/doc/guides/rel_notes/release_22_07.rst +++ b/doc/guides/rel_notes/release_22_07.rst @@ -55,6 +55,13 @@ New Features Also, make sure to start the actual text at the margin. === +* **Added protocol based input color selection for meter.** + + Added new APIs ``rte_mtr_color_in_protocol_set()``, ``rte_mtr_color_in_protocol_get()``, + ``rte_mtr_color_in_protocol_
[dpdk-dev] [PATCH] doc: fix build error with sphinx 4.5.0
From: Jerin Jacob
Latest sphinx checks c language syntax more aggressively.
Fix the following warning by correcting c language syntax.
doc/guides/prog_guide/event_ethernet_rx_adapter.rst:243:
WARNING: Could not lex literal_block as "c". Highlighting skipped.
Fixes: 3c838062b91f ("eventdev: introduce event vector Rx capability")
Cc: Pavan Nikhilesh
Cc: sta...@dpdk.org
Signed-off-by: Jerin Jacob
---
doc/guides/prog_guide/event_ethernet_rx_adapter.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
index 67b11e1563..3b4ef502b2 100644
--- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
+++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
@@ -257,8 +257,8 @@ A loop processing ``rte_event_vector`` containing mbufs is
shown below.
/* Process each mbuf. */
}
break;
-case ...
-...
+case default:
+/* Handle other event_types. */
}
Rx event vectorization for SW Rx adapter
--
2.36.0
when dpdk-process is running, server machine breakdown while offload igb_uio or vfio_pci.
hi??i'm so sorry to disturb, but i got a question which stuck me for a long time. when dpdk-process is running, assuming that dpdk use a NIC named eth0, and eth0 insmod a i40e drivers before, then when i offload the NIC from igb_uio/vfio_pci to i40e, and stop the dpdk-process . my server machine will shutdown. i wonder how can i stop this happen? looking forward to your reply! thank you very much best regards linux kernel : Linux localhost.localdomain 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13 17:20:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux centos : 7.4
Re: [PATCH v4 2/7] examples/ipsec-secgw: disable Tx chksum offload for inline
29/04/2022 21:44, Nithin Dabilpuram пишет:
Enable Tx IPv4 checksum offload only when Tx inline crypto, lookaside
crypto/protocol or cpu crypto is needed.
For Tx Inline protocol offload, checksum computation
is implicitly taken care by HW.
Signed-off-by: Nithin Dabilpuram
Acked-by: Akhil Goyal
---
examples/ipsec-secgw/ipsec-secgw.c | 3 ---
examples/ipsec-secgw/sa.c | 46 --
2 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec-secgw.c
b/examples/ipsec-secgw/ipsec-secgw.c
index 959a20b..5fe5eee 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1761,9 +1761,6 @@ port_init(uint16_t portid, uint64_t req_rx_offloads,
uint64_t req_tx_offloads)
local_port_conf.txmode.offloads |=
RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE;
- if (dev_info.tx_offload_capa & RTE_ETH_TX_OFFLOAD_IPV4_CKSUM)
- local_port_conf.txmode.offloads |=
RTE_ETH_TX_OFFLOAD_IPV4_CKSUM;
-
printf("port %u configuring rx_offloads=0x%" PRIx64
", tx_offloads=0x%" PRIx64 "\n",
portid, local_port_conf.rxmode.offloads,
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 1839ac7..e8f2598 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -1766,10 +1766,18 @@ sa_check_offloads(uint16_t port_id, uint64_t
*rx_offloads,
struct ipsec_sa *rule;
uint32_t idx_sa;
enum rte_security_session_action_type rule_type;
+ struct rte_eth_dev_info dev_info;
+ int ret;
*rx_offloads = 0;
*tx_offloads = 0;
+ ret = rte_eth_dev_info_get(port_id, &dev_info);
+ if (ret != 0)
+ rte_exit(EXIT_FAILURE,
+ "Error during getting device (port %u) info: %s\n",
+ port_id, strerror(-ret));
+
/* Check for inbound rules that use offloads and use this port */
for (idx_sa = 0; idx_sa < nb_sa_in; idx_sa++) {
rule = &sa_in[idx_sa];
@@ -1785,13 +1793,37 @@ sa_check_offloads(uint16_t port_id, uint64_t
*rx_offloads,
for (idx_sa = 0; idx_sa < nb_sa_out; idx_sa++) {
rule = &sa_out[idx_sa];
rule_type = ipsec_get_action_type(rule);
- if ((rule_type == RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO ||
- rule_type ==
- RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL)
- && rule->portid == port_id) {
- *tx_offloads |= RTE_ETH_TX_OFFLOAD_SECURITY;
- if (rule->mss)
- *tx_offloads |= RTE_ETH_TX_OFFLOAD_TCP_TSO;
+ switch (rule_type) {
+ case RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
+ /* Checksum offload is not needed for inline protocol as
+* all processing for Outbound IPSec packets will be
+* implicitly taken care and for non-IPSec packets,
+* there is no need of IPv4 Checksum offload.
+*/
+ if (rule->portid == port_id) {
+ *tx_offloads |= RTE_ETH_TX_OFFLOAD_SECURITY;
+ if (rule->mss)
+ *tx_offloads |=
(RTE_ETH_TX_OFFLOAD_TCP_TSO |
+
RTE_ETH_TX_OFFLOAD_IPV4_CKSUM);
+ }
+ break;
+ case RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
+ if (rule->portid == port_id) {
+ *tx_offloads |= RTE_ETH_TX_OFFLOAD_SECURITY;
+ if (rule->mss)
+ *tx_offloads |=
+ RTE_ETH_TX_OFFLOAD_TCP_TSO;
+ *tx_offloads |= RTE_ETH_TX_OFFLOAD_IPV4_CKSUM;
+ }
+ break;
+ default:
+ /* Enable IPv4 checksum offload even if one of lookaside
+* SA's are present.
+*/
+ if (dev_info.tx_offload_capa &
+ RTE_ETH_TX_OFFLOAD_IPV4_CKSUM)
+ *tx_offloads |= RTE_ETH_TX_OFFLOAD_IPV4_CKSUM;
+ break;
}
}
return 0;
Acked-by: Konstantin Ananyev
RE: [PATCH v3 2/7] crypto/cnxk: add event metadata set operation
> > -uint16_t
> > -cn10k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct rte_crypto_op
> > *op)
> > +static int
> > +cn10k_cpt_crypto_adapter_ev_mdata_set(struct rte_cryptodev *dev
> > __rte_unused,
> > + void *sess,
> > + enum rte_crypto_op_type op_type,
> > + enum rte_crypto_op_sess_type sess_type,
> > + void *mdata)
> > {
> > - union rte_event_crypto_metadata *ec_mdata;
> > - struct cpt_inflight_req *infl_req;
> > + union rte_event_crypto_metadata *ec_mdata = mdata;
> > struct rte_event *rsp_info;
> > - uint64_t lmt_base, lmt_arg;
> > - struct cpt_inst_s *inst;
> > struct cnxk_cpt_qp *qp;
> > uint8_t cdev_id;
> > - uint16_t lmt_id;
> > - uint16_t qp_id;
> > - int ret;
> > -
> > - ec_mdata = cnxk_event_crypto_mdata_get(op);
> > - if (!ec_mdata) {
> > - rte_errno = EINVAL;
> > - return 0;
> > - }
> > + int16_t qp_id;
> > + uint64_t w2;
> >
> > + /* Get queue pair */
> > cdev_id = ec_mdata->request_info.cdev_id;
> > qp_id = ec_mdata->request_info.queue_pair_id;
> > qp = rte_cryptodevs[cdev_id].data->queue_pairs[qp_id];
> > +
> > + /* Prepare w2 */
> > rsp_info = &ec_mdata->response_info;
> > + w2 = CNXK_CPT_INST_W2(
> > + (RTE_EVENT_TYPE_CRYPTODEV << 28) | rsp_info->flow_id,
> > + rsp_info->sched_type, rsp_info->queue_id, 0);
> > +
> > + /* Set meta according to session type */
> > + if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
> > + if (sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
> > + struct cn10k_sec_session *priv;
> > + struct cn10k_ipsec_sa *sa;
> > +
> > + priv = get_sec_session_private_data(sess);
> > + sa = &priv->sa;
> > + sa->qp = qp;
> > + sa->inst.w2 = w2;
> > + } else if (sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> > + struct cnxk_se_sess *priv;
> > +
> > + priv = get_sym_session_private_data(
> > + sess, cn10k_cryptodev_driver_id);
> > + priv->qp = qp;
> > + priv->cpt_inst_w2 = w2;
> > + } else
> cnXX_ca_meta_info_extract() supports SESSIONLESS case. But no support here.
> Is this expected?
This function is for setting the event metadata in session, but in case of
sessionless
there are no sessions, so event metadata is extracted in a different way.
Hence this is correct.
RE: [PATCH v3 6/7] test/event: add asymmetric cases for crypto adapter
Hi Abhinandan,
> >
> > > This is failing with asym changes. Please look into this.
> >
> > Thanks for pointing this out. It is failing as null crypto does not support
> > asym
> > And asym_session_create would need an op from driver which is NULL for null
> > crypto
> >
> > Please check if below change is working for you.
> I could not apply this patch cleanly. I see that you are skipping the asym
> test for
> NULL PMD.
> Can I use openssl or any open source PMD to test this feature? If yes, please
> provide the command line.
The patch is not skipping specifically null pmd.
It is not creating asym session and asym op mempools for devices which do not
Support asym sessions.
OpenSSL can be used as it support asym ops(vdev can be passed as command line
arg),
But the test will not execute, as it would not support event crypto adapter.
This patch can be tested with PMD which support ASYM crypto adapter and no other
PMD support that as of now.
> >
> > diff --git a/app/test/test_event_crypto_adapter.c
> > b/app/test/test_event_crypto_adapter.c
> > index eecfc22057..2ecc7e2cea 100644
> > --- a/app/test/test_event_crypto_adapter.c
> > +++ b/app/test/test_event_crypto_adapter.c
> > @@ -934,13 +934,16 @@ test_asym_session_with_op_new_mode(void)
> > static int
> > configure_cryptodev(void)
> > {
> > + const struct rte_cryptodev_capabilities *capability;
> > struct rte_cryptodev_qp_conf qp_conf;
> > struct rte_cryptodev_config conf;
> > struct rte_cryptodev_info info;
> > unsigned int session_size;
> > + unsigned int i = 0;
> > uint8_t nb_devs;
> > int ret;
> >
> > +
> > params.mbuf_pool = rte_pktmbuf_pool_create(
> > "CRYPTO_ADAPTER_MBUFPOOL",
> > NUM_MBUFS, MBUF_CACHE_SIZE, 0, MBUF_SIZE, @@ -963,19
> > +966,6 @@ configure_cryptodev(void)
> > RTE_LOG(ERR, USER1, "Can't create CRYPTO_OP_POOL\n");
> > return TEST_FAILED;
> > }
> > - params.asym_op_mpool = rte_crypto_op_pool_create(
> > - "EVENT_CRYPTO_ASYM_OP_POOL",
> > - RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
> > - NUM_MBUFS, MBUF_CACHE_SIZE,
> > - (DEFAULT_NUM_XFORMS *
> > - sizeof(struct rte_crypto_asym_xform)) +
> > - sizeof(union rte_event_crypto_metadata),
> > - rte_socket_id());
> > - if (params.asym_op_mpool == NULL) {
> > - RTE_LOG(ERR, USER1, "Can't create CRYPTO_ASYM_OP_POOL\n");
> > - return TEST_FAILED;
> > - }
> > -
> >
> > /* Create a NULL crypto device */
> > nb_devs = rte_cryptodev_device_count_by_driver(
> > @@ -1020,16 +1010,34 @@ configure_cryptodev(void)
> > TEST_ASSERT_NOT_NULL(params.session_priv_mpool,
> > "session mempool allocation failed\n");
> >
> > - params.asym_sess_mpool = rte_cryptodev_asym_session_pool_create(
> > - "CRYPTO_AD_ASYM_SESS_MP",
> > - MAX_NB_SESSIONS, 0,
> > - sizeof(union rte_event_crypto_metadata),
> > - SOCKET_ID_ANY);
> > - TEST_ASSERT_NOT_NULL(params.asym_sess_mpool,
> > - "asym session mempool allocation failed\n");
> > -
> > -
> > rte_cryptodev_info_get(TEST_CDEV_ID, &info);
> > +
> > + while ((capability = &info.capabilities[i++])->op !=
> > + RTE_CRYPTO_OP_TYPE_UNDEFINED) {
> > + if (capability->op == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
> > + params.asym_op_mpool = rte_crypto_op_pool_create(
> > + "EVENT_CRYPTO_ASYM_OP_POOL",
> > + RTE_CRYPTO_OP_TYPE_ASYMMETRIC,
> > + NUM_MBUFS, MBUF_CACHE_SIZE,
> > + (DEFAULT_NUM_XFORMS *
> > + sizeof(struct rte_crypto_asym_xform)) +
> > + sizeof(union rte_event_crypto_metadata),
> > + rte_socket_id());
> > + TEST_ASSERT_NOT_NULL(params.asym_op_mpool,
> > + "Can't create
> > + CRYPTO_ASYM_OP_POOL\n");
> > +
> > + params.asym_sess_mpool =
> > + rte_cryptodev_asym_session_pool_create(
> > + "CRYPTO_AD_ASYM_SESS_MP",
> > + MAX_NB_SESSIONS, 0,
> > + sizeof(union
> > rte_event_crypto_metadata),
> > + SOCKET_ID_ANY);
> > + TEST_ASSERT_NOT_NULL(params.asym_sess_mpool,
> > + "asym session mempool allocation failed\n");
> > + break;
> > + }
> > + }
RE: [PATCH v3 1/7] cryptodev: add APIs to get/set event metadata
> > > > +
> > > > +void *
> > > > +rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op) {
> > > Null check for op?
> >
> > Null check can be added, but this a datapath dpdk internal API.
> > We do not normally add checks in datapath.
> > If you insist, I can add, but before calling this API, PMD/lib would have
> > already
> > checked for null op.
> It is ok for get API. It is better to add the check for set API as it exposed
> to user
> application.
> Currently, the set API is validating dev_id. It is better to add a null check
> only for
> set API.
Ok. Will do that.
[PATCH v4 0/7] Add new cryptodev op for event metadata
For using event crypto metadata, event metadata need to be set in session. For this session user data was used for symmetric crypto sessions and no support was present for asymmetric and security sessions. The use of userdata to store event metadata (which is dereferenced in PMD) is not correct as it is meant for the application to use it. Hence, a new API is created to set and get event crypto metadata which is scalable to all sessions supported by the crypto PMD. The application can use the set API to set event metadata and the PMD may store that inside the session private data and PMD need not use the get API as it would be internal to the PMD. For the software event crypto adapter implementation, the eventdev library can use the get API to get the event metadata stored inside the session structure. For Asymmetric sessions, a new field is added inside the session struct which is internal to library. For symmetric and security sessions, new field cannot be added as it would be ABI break. Hence, session userdata is being used to store that as it was used earlier. In next ABI break release this would be fixed similar to asymmetric crypto case. The patchset also add support for asymmetric crypto adapter in the test applications and the crypto/cnxk implementation of the new cryptodev op and corresponding changes in the eventdev lib. Changes in v4: - added null checks in set API - updated check in session destroy - updated API comments - fixed test app failure reported by Abhinandan. - moved event mdata after padding in asym session struct. Changes in v3: - fix SW adapter case of memory allocation/free of mdata. mdata is allocated in set API and freed in session clear/destroy. - mark rte_cryptodev_session_event_mdata_get as internal API as it is only needed for the app or the PMD. changes in v2: - v1 patchset only fixed security sessions and also caused ABI breakage. This is fixed in v2. - added new API for setting event metadata. - added new cryptodev op which can handle all sessions Akhil Goyal (5): crypto/octeontx: use new API for event metadata test/event: use new API to set event crypto metadata eventdev: use new API to get event crypto metadata test/event: add asymmetric cases for crypto adapter test-eventdev: support asym ops for crypto adapter Volodymyr Fialko (2): cryptodev: add APIs to get/set event metadata crypto/cnxk: add event metadata set operation app/test-eventdev/evt_common.h | 2 + app/test-eventdev/evt_options.c | 17 + app/test-eventdev/evt_options.h | 4 + app/test-eventdev/test_perf_atq.c | 12 +- app/test-eventdev/test_perf_common.c| 254 -- app/test-eventdev/test_perf_common.h| 45 +- app/test-eventdev/test_perf_queue.c | 12 +- app/test/test_event_crypto_adapter.c| 511 +++- doc/guides/tools/testeventdev.rst | 5 + drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +- drivers/crypto/cnxk/cn10k_ipsec.h | 2 + drivers/crypto/cnxk/cn9k_cryptodev_ops.c| 138 +- drivers/crypto/cnxk/cn9k_ipsec.h| 2 + drivers/crypto/cnxk/cnxk_ae.h | 2 + drivers/crypto/cnxk/cnxk_cryptodev_ops.h| 18 - drivers/crypto/cnxk/cnxk_se.h | 2 + drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +- lib/cryptodev/cryptodev_pmd.c | 16 + lib/cryptodev/cryptodev_pmd.h | 36 ++ lib/cryptodev/rte_cryptodev.c | 44 ++ lib/cryptodev/rte_cryptodev.h | 22 + lib/cryptodev/version.map | 4 + lib/eventdev/rte_event_crypto_adapter.c | 55 +-- 23 files changed, 1179 insertions(+), 188 deletions(-) -- 2.25.1
[PATCH v4 1/7] cryptodev: add APIs to get/set event metadata
From: Volodymyr Fialko
Currently, crypto session userdata is used to set event crypto
metadata from the application and the driver is dereferencing it
in driver which is not correct. User data is meant to be opaque
to the driver.
To support this, new API is added to get and set event crypto
metadata. The new API, rte_cryptodev_set_session_event_mdata,
allows setting event metadata in session private data which is
filled inside PMD using a new cryptodev op. This operation
can be performed on any of the PMD supported sessions
(sym/asym/security).
For SW abstraction of event crypto adapter to be used by
eventdev library, a new field is added in asymmetric crypto
session for now and for symmetric case, current implementation
of using userdata is used. Symmetric cases cannot be fixed now,
as it will be ABI breakage which will be resolved in DPDK 22.11.
Signed-off-by: Volodymyr Fialko
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
---
lib/cryptodev/cryptodev_pmd.c | 16 +
lib/cryptodev/cryptodev_pmd.h | 36
lib/cryptodev/rte_cryptodev.c | 44 +++
lib/cryptodev/rte_cryptodev.h | 22 ++
lib/cryptodev/version.map | 4
5 files changed, 122 insertions(+)
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 739a0b3f34..1903ade388 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -227,3 +227,19 @@ cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
fp_ops->qp.enq_cb = dev->enq_cbs;
fp_ops->qp.deq_cb = dev->deq_cbs;
}
+
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op)
+{
+ if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return
rte_cryptodev_sym_session_get_user_data(op->sym->session);
+ else if (op->type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC &&
+ op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
+ return op->asym->session->event_mdata;
+ else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
+ op->private_data_offset)
+ return ((uint8_t *)op + op->private_data_offset);
+ else
+ return NULL;
+}
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 2b1ce2da2d..7a7d3ee3f1 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -398,6 +398,25 @@ typedef int (*cryptodev_sym_configure_raw_dp_ctx_t)(
enum rte_crypto_op_sess_type sess_type,
union rte_cryptodev_session_ctx session_ctx, uint8_t is_update);
+/**
+ * Typedef that the driver provided to set event crypto meta data.
+ *
+ * @param dev Crypto device pointer.
+ * @param sessCrypto or security session.
+ * @param op_type Operation type.
+ * @param sess_type Session type.
+ * @param ev_mdataPointer to the event crypto meta data
+ * (aka *union rte_event_crypto_metadata*)
+ * @return
+ * - On success return 0.
+ * - On failure return negative integer.
+ */
+typedef int (*cryptodev_session_event_mdata_set_t)(
+ struct rte_cryptodev *dev, void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *ev_mdata);
+
/** Crypto device operations function pointer table */
struct rte_cryptodev_ops {
cryptodev_configure_t dev_configure;/**< Configure device. */
@@ -442,6 +461,8 @@ struct rte_cryptodev_ops {
/**< Initialize raw data path context data. */
};
};
+ cryptodev_session_event_mdata_set_t session_ev_mdata_set;
+ /**< Set a Crypto or Security session even meta data. */
};
@@ -603,6 +624,19 @@ void
cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
const struct rte_cryptodev *dev);
+/**
+ * Get session event meta data (aka *union rte_event_crypto_metadata*)
+ *
+ * @param oppointer to *rte_crypto_op* structure.
+ *
+ * @return
+ * - On success, pointer to event crypto metadata
+ * - On failure, NULL.
+ */
+__rte_internal
+void *
+rte_cryptodev_session_event_mdata_get(struct rte_crypto_op *op);
+
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
@@ -637,6 +671,8 @@ RTE_STD_C11 struct rte_cryptodev_asym_session {
uint16_t user_data_sz;
/**< Session user data will be placed after sess_data */
uint8_t padding[3];
+ void *event_mdata;
+ /**< Event metadata (aka *union rte_event_crypto_metadata*) */
uint8_t sess_private_data[0];
};
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 3500a2d470..5ebc423afa 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
[PATCH v4 2/7] crypto/cnxk: add event metadata set operation
From: Volodymyr Fialko
Added cryptodev operation for setting event crypto
metadata for all supported sessions - sym/asym/security.
Signed-off-by: Volodymyr Fialko
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
Acked-by: Abhinandan Gujjar
---
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 144 +++---
drivers/crypto/cnxk/cn10k_ipsec.h | 2 +
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 138 ++---
drivers/crypto/cnxk/cn9k_ipsec.h | 2 +
drivers/crypto/cnxk/cnxk_ae.h | 2 +
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 18 ---
drivers/crypto/cnxk/cnxk_se.h | 2 +
7 files changed, 255 insertions(+), 53 deletions(-)
diff --git a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
index c4d5d039ec..01aa0d6870 100644
--- a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
@@ -264,30 +264,136 @@ cn10k_cpt_enqueue_burst(void *qptr, struct rte_crypto_op
**ops, uint16_t nb_ops)
return count + i;
}
-uint16_t
-cn10k_cpt_crypto_adapter_enqueue(uintptr_t tag_op, struct rte_crypto_op *op)
+static int
+cn10k_cpt_crypto_adapter_ev_mdata_set(struct rte_cryptodev *dev __rte_unused,
+ void *sess,
+ enum rte_crypto_op_type op_type,
+ enum rte_crypto_op_sess_type sess_type,
+ void *mdata)
{
- union rte_event_crypto_metadata *ec_mdata;
- struct cpt_inflight_req *infl_req;
+ union rte_event_crypto_metadata *ec_mdata = mdata;
struct rte_event *rsp_info;
- uint64_t lmt_base, lmt_arg;
- struct cpt_inst_s *inst;
struct cnxk_cpt_qp *qp;
uint8_t cdev_id;
- uint16_t lmt_id;
- uint16_t qp_id;
- int ret;
-
- ec_mdata = cnxk_event_crypto_mdata_get(op);
- if (!ec_mdata) {
- rte_errno = EINVAL;
- return 0;
- }
+ int16_t qp_id;
+ uint64_t w2;
+ /* Get queue pair */
cdev_id = ec_mdata->request_info.cdev_id;
qp_id = ec_mdata->request_info.queue_pair_id;
qp = rte_cryptodevs[cdev_id].data->queue_pairs[qp_id];
+
+ /* Prepare w2 */
rsp_info = &ec_mdata->response_info;
+ w2 = CNXK_CPT_INST_W2(
+ (RTE_EVENT_TYPE_CRYPTODEV << 28) | rsp_info->flow_id,
+ rsp_info->sched_type, rsp_info->queue_id, 0);
+
+ /* Set meta according to session type */
+ if (op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
+ if (sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
+ struct cn10k_sec_session *priv;
+ struct cn10k_ipsec_sa *sa;
+
+ priv = get_sec_session_private_data(sess);
+ sa = &priv->sa;
+ sa->qp = qp;
+ sa->inst.w2 = w2;
+ } else if (sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
+ struct cnxk_se_sess *priv;
+
+ priv = get_sym_session_private_data(
+ sess, cn10k_cryptodev_driver_id);
+ priv->qp = qp;
+ priv->cpt_inst_w2 = w2;
+ } else
+ return -EINVAL;
+ } else if (op_type == RTE_CRYPTO_OP_TYPE_ASYMMETRIC) {
+ if (sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
+ struct rte_cryptodev_asym_session *asym_sess = sess;
+ struct cnxk_ae_sess *priv;
+
+ priv = (struct cnxk_ae_sess
*)asym_sess->sess_private_data;
+ priv->qp = qp;
+ priv->cpt_inst_w2 = w2;
+ } else
+ return -EINVAL;
+ } else
+ return -EINVAL;
+
+ return 0;
+}
+
+static inline int
+cn10k_ca_meta_info_extract(struct rte_crypto_op *op,
+struct cnxk_cpt_qp **qp, uint64_t *w2)
+{
+ if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
+ if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
+ struct cn10k_sec_session *priv;
+ struct cn10k_ipsec_sa *sa;
+
+ priv =
get_sec_session_private_data(op->sym->sec_session);
+ sa = &priv->sa;
+ *qp = sa->qp;
+ *w2 = sa->inst.w2;
+ } else if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
+ struct cnxk_se_sess *priv;
+
+ priv = get_sym_session_private_data(
+ op->sym->session, cn10k_cryptodev_driver_id);
+ *qp = priv->qp;
+ *w2 = priv->cpt_inst_w2;
+ } else {
+ union rte_event_crypto_metadata *ec_mdata;
+ stru
[PATCH v4 3/7] crypto/octeontx: use new API for event metadata
For getting event crypto metadata from crypto_op,
the new API rte_cryptodev_get_session_event_mdata can be used
directly instead of getting userdata inside PMD.
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
Acked-by: Abhinandan Gujjar
---
drivers/crypto/octeontx/otx_cryptodev_ops.c | 20 +---
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c
b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index ddb1266c3c..d5851d9987 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -684,24 +684,6 @@ submit_request_to_sso(struct ssows *ws, uintptr_t req,
ssovf_store_pair(add_work, req, ws->grps[rsp_info->queue_id]);
}
-static inline union rte_event_crypto_metadata *
-get_event_crypto_mdata(struct rte_crypto_op *op)
-{
- union rte_event_crypto_metadata *ec_mdata;
-
- if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
- ec_mdata = rte_cryptodev_sym_session_get_user_data(
- op->sym->session);
- else if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
-op->private_data_offset)
- ec_mdata = (union rte_event_crypto_metadata *)
- ((uint8_t *)op + op->private_data_offset);
- else
- return NULL;
-
- return ec_mdata;
-}
-
uint16_t __rte_hot
otx_crypto_adapter_enqueue(void *port, struct rte_crypto_op *op)
{
@@ -712,7 +694,7 @@ otx_crypto_adapter_enqueue(void *port, struct rte_crypto_op
*op)
uint8_t op_type, cdev_id;
uint16_t qp_id;
- ec_mdata = get_event_crypto_mdata(op);
+ ec_mdata = rte_cryptodev_session_event_mdata_get(op);
if (unlikely(ec_mdata == NULL)) {
rte_errno = EINVAL;
return 0;
--
2.25.1
[PATCH v4 4/7] test/event: use new API to set event crypto metadata
Used the new API rte_cryptodev_set_session_event_mdata to set
event crypto metadata from the applications (app/test and
app/test-eventdev) instead of using session userdata.
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
Acked-by: Abhinandan Gujjar
---
app/test-eventdev/test_perf_common.c | 8 ++--
app/test/test_event_crypto_adapter.c | 12
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/app/test-eventdev/test_perf_common.c
b/app/test-eventdev/test_perf_common.c
index 9d1f4a4567..0378607cda 100644
--- a/app/test-eventdev/test_perf_common.c
+++ b/app/test-eventdev/test_perf_common.c
@@ -835,8 +835,12 @@ perf_event_dev_port_setup(struct evt_test *test, struct
evt_options *opt,
return -ENOMEM;
m_data.response_info.flow_id = flow_id;
- rte_cryptodev_sym_session_set_user_data(
- crypto_sess, &m_data, sizeof(m_data));
+ rte_cryptodev_session_event_mdata_set(cdev_id,
+ crypto_sess,
+ RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ RTE_CRYPTO_OP_WITH_SESSION,
+ &m_data, sizeof(m_data));
+
p->ca.crypto_sess[flow_id] = crypto_sess;
}
diff --git a/app/test/test_event_crypto_adapter.c
b/app/test/test_event_crypto_adapter.c
index 688520db4e..9904206735 100644
--- a/app/test/test_event_crypto_adapter.c
+++ b/app/test/test_event_crypto_adapter.c
@@ -227,8 +227,10 @@ test_op_forward_mode(uint8_t session_less)
m_data.request_info.queue_pair_id =
request_info.queue_pair_id;
m_data.response_info.event = response_info.event;
- rte_cryptodev_sym_session_set_user_data(sess,
- &m_data, sizeof(m_data));
+ rte_cryptodev_session_event_mdata_set(TEST_CDEV_ID,
+ sess, RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ RTE_CRYPTO_OP_WITH_SESSION,
+ &m_data, sizeof(m_data));
}
rte_crypto_op_attach_sym_session(op, sess);
@@ -416,8 +418,10 @@ test_op_new_mode(uint8_t session_less)
if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA) {
/* Fill in private user data information */
m_data.response_info.event = response_info.event;
- rte_cryptodev_sym_session_set_user_data(sess,
- &m_data, sizeof(m_data));
+ rte_cryptodev_session_event_mdata_set(TEST_CDEV_ID,
+ sess, RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ RTE_CRYPTO_OP_WITH_SESSION,
+ &m_data, sizeof(m_data));
}
ret = rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
&cipher_xform, params.session_priv_mpool);
--
2.25.1
[PATCH v4 5/7] eventdev: use new API to get event crypto metadata
For getting event crypto metadata from crypto_op,
the new API rte_cryptodev_get_session_event_mdata is used
instead of getting userdata inside PMD.
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
Acked-by: Abhinandan Gujjar
---
lib/eventdev/rte_event_crypto_adapter.c | 55 ++---
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/lib/eventdev/rte_event_crypto_adapter.c
b/lib/eventdev/rte_event_crypto_adapter.c
index f624f50187..7c695176f4 100644
--- a/lib/eventdev/rte_event_crypto_adapter.c
+++ b/lib/eventdev/rte_event_crypto_adapter.c
@@ -457,43 +457,22 @@ eca_enq_to_cryptodev(struct event_crypto_adapter
*adapter, struct rte_event *ev,
crypto_op = ev[i].event_ptr;
if (crypto_op == NULL)
continue;
- if (crypto_op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
- m_data = rte_cryptodev_sym_session_get_user_data(
- crypto_op->sym->session);
- if (m_data == NULL) {
- rte_pktmbuf_free(crypto_op->sym->m_src);
- rte_crypto_op_free(crypto_op);
- continue;
- }
+ m_data = rte_cryptodev_session_event_mdata_get(crypto_op);
+ if (m_data == NULL) {
+ rte_pktmbuf_free(crypto_op->sym->m_src);
+ rte_crypto_op_free(crypto_op);
+ continue;
+ }
- cdev_id = m_data->request_info.cdev_id;
- qp_id = m_data->request_info.queue_pair_id;
- qp_info = &adapter->cdevs[cdev_id].qpairs[qp_id];
- if (!qp_info->qp_enabled) {
- rte_pktmbuf_free(crypto_op->sym->m_src);
- rte_crypto_op_free(crypto_op);
- continue;
- }
- eca_circular_buffer_add(&qp_info->cbuf, crypto_op);
- } else if (crypto_op->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
- crypto_op->private_data_offset) {
- m_data = (union rte_event_crypto_metadata *)
-((uint8_t *)crypto_op +
- crypto_op->private_data_offset);
- cdev_id = m_data->request_info.cdev_id;
- qp_id = m_data->request_info.queue_pair_id;
- qp_info = &adapter->cdevs[cdev_id].qpairs[qp_id];
- if (!qp_info->qp_enabled) {
- rte_pktmbuf_free(crypto_op->sym->m_src);
- rte_crypto_op_free(crypto_op);
- continue;
- }
- eca_circular_buffer_add(&qp_info->cbuf, crypto_op);
- } else {
+ cdev_id = m_data->request_info.cdev_id;
+ qp_id = m_data->request_info.queue_pair_id;
+ qp_info = &adapter->cdevs[cdev_id].qpairs[qp_id];
+ if (!qp_info->qp_enabled) {
rte_pktmbuf_free(crypto_op->sym->m_src);
rte_crypto_op_free(crypto_op);
continue;
}
+ eca_circular_buffer_add(&qp_info->cbuf, crypto_op);
if (eca_circular_buffer_batch_ready(&qp_info->cbuf)) {
ret = eca_circular_buffer_flush_to_cdev(&qp_info->cbuf,
@@ -636,17 +615,7 @@ eca_ops_enqueue_burst(struct event_crypto_adapter *adapter,
for (i = 0; i < num; i++) {
struct rte_event *ev = &events[nb_ev++];
- m_data = NULL;
- if (ops[i]->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
- m_data = rte_cryptodev_sym_session_get_user_data(
- ops[i]->sym->session);
- } else if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS &&
- ops[i]->private_data_offset) {
- m_data = (union rte_event_crypto_metadata *)
-((uint8_t *)ops[i] +
- ops[i]->private_data_offset);
- }
-
+ m_data = rte_cryptodev_session_event_mdata_get(ops[i]);
if (unlikely(m_data == NULL)) {
rte_pktmbuf_free(ops[i]->sym->m_src);
rte_crypto_op_free(ops[i]);
--
2.25.1
[PATCH v4 6/7] test/event: add asymmetric cases for crypto adapter
Test app is updated to add cases for asymmetric crypto
sessions for event crypto adapter.
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
---
app/test/test_event_crypto_adapter.c | 499 ++-
1 file changed, 493 insertions(+), 6 deletions(-)
diff --git a/app/test/test_event_crypto_adapter.c
b/app/test/test_event_crypto_adapter.c
index 9904206735..2ecc7e2cea 100644
--- a/app/test/test_event_crypto_adapter.c
+++ b/app/test/test_event_crypto_adapter.c
@@ -6,6 +6,7 @@
#include "test.h"
#include
#include
+#include
#include
#include
#include
@@ -67,12 +68,97 @@ static const uint8_t text_64B[] = {
0x31, 0xbf, 0xe9, 0xa1, 0x97, 0x5c, 0x2b, 0xd6,
0x57, 0xa5, 0x9f, 0xab, 0xbd, 0xb0, 0x9b, 0x9c
};
+#define DATA_SIZE 512
+struct modex_test_data {
+ enum rte_crypto_asym_xform_type xform_type;
+ struct {
+ uint8_t data[DATA_SIZE];
+ uint16_t len;
+ } base;
+ struct {
+ uint8_t data[DATA_SIZE];
+ uint16_t len;
+ } exponent;
+ struct {
+ uint8_t data[DATA_SIZE];
+ uint16_t len;
+ } modulus;
+ struct {
+ uint8_t data[DATA_SIZE];
+ uint16_t len;
+ } reminder;
+ uint16_t result_len;
+};
+
+static struct
+modex_test_data modex_test_case = {
+ .xform_type = RTE_CRYPTO_ASYM_XFORM_MODEX,
+ .base = {
+ .data = {
+ 0xF8, 0xBA, 0x1A, 0x55, 0xD0, 0x2F, 0x85,
+ 0xAE, 0x96, 0x7B, 0xB6, 0x2F, 0xB6, 0xCD,
+ 0xA8, 0xEB, 0x7E, 0x78, 0xA0, 0x50
+ },
+ .len = 20,
+ },
+ .exponent = {
+ .data = {
+ 0x01, 0x00, 0x01
+ },
+ .len = 3,
+ },
+ .reminder = {
+ .data = {
+ 0x2C, 0x60, 0x75, 0x45, 0x98, 0x9D, 0xE0, 0x72,
+ 0xA0, 0x9D, 0x3A, 0x9E, 0x03, 0x38, 0x73, 0x3C,
+ 0x31, 0x83, 0x04, 0xFE, 0x75, 0x43, 0xE6, 0x17,
+ 0x5C, 0x01, 0x29, 0x51, 0x69, 0x33, 0x62, 0x2D,
+ 0x78, 0xBE, 0xAE, 0xC4, 0xBC, 0xDE, 0x7E, 0x2C,
+ 0x77, 0x84, 0xF2, 0xC5, 0x14, 0xB5, 0x2F, 0xF7,
+ 0xC5, 0x94, 0xEF, 0x86, 0x75, 0x75, 0xB5, 0x11,
+ 0xE5, 0x0E, 0x0A, 0x29, 0x76, 0xE2, 0xEA, 0x32,
+ 0x0E, 0x43, 0x77, 0x7E, 0x2C, 0x27, 0xAC, 0x3B,
+ 0x86, 0xA5, 0xDB, 0xC9, 0x48, 0x40, 0xE8, 0x99,
+ 0x9A, 0x0A, 0x3D, 0xD6, 0x74, 0xFA, 0x2E, 0x2E,
+ 0x5B, 0xAF, 0x8C, 0x99, 0x44, 0x2A, 0x67, 0x38,
+ 0x27, 0x41, 0x59, 0x9D, 0xB8, 0x51, 0xC9, 0xF7,
+ 0x43, 0x61, 0x31, 0x6E, 0xF1, 0x25, 0x38, 0x7F,
+ 0xAE, 0xC6, 0xD0, 0xBB, 0x29, 0x76, 0x3F, 0x46,
+ 0x2E, 0x1B, 0xE4, 0x67, 0x71, 0xE3, 0x87, 0x5A
+ },
+ .len = 128,
+ },
+ .modulus = {
+ .data = {
+ 0xb3, 0xa1, 0xaf, 0xb7, 0x13, 0x08, 0x00, 0x0a,
+ 0x35, 0xdc, 0x2b, 0x20, 0x8d, 0xa1, 0xb5, 0xce,
+ 0x47, 0x8a, 0xc3, 0x80, 0xf4, 0x7d, 0x4a, 0xa2,
+ 0x62, 0xfd, 0x61, 0x7f, 0xb5, 0xa8, 0xde, 0x0a,
+ 0x17, 0x97, 0xa0, 0xbf, 0xdf, 0x56, 0x5a, 0x3d,
+ 0x51, 0x56, 0x4f, 0x70, 0x70, 0x3f, 0x63, 0x6a,
+ 0x44, 0x5b, 0xad, 0x84, 0x0d, 0x3f, 0x27, 0x6e,
+ 0x3b, 0x34, 0x91, 0x60, 0x14, 0xb9, 0xaa, 0x72,
+ 0xfd, 0xa3, 0x64, 0xd2, 0x03, 0xa7, 0x53, 0x87,
+ 0x9e, 0x88, 0x0b, 0xc1, 0x14, 0x93, 0x1a, 0x62,
+ 0xff, 0xb1, 0x5d, 0x74, 0xcd, 0x59, 0x63, 0x18,
+ 0x11, 0x3d, 0x4f, 0xba, 0x75, 0xd4, 0x33, 0x4e,
+ 0x23, 0x6b, 0x7b, 0x57, 0x44, 0xe1, 0xd3, 0x03,
+ 0x13, 0xa6, 0xf0, 0x8b, 0x60, 0xb0, 0x9e, 0xee,
+ 0x75, 0x08, 0x9d, 0x71, 0x63, 0x13, 0xcb, 0xa6,
+ 0x81, 0x92, 0x14, 0x03, 0x22, 0x2d, 0xde, 0x55
+ },
+ .len = 128,
+ },
+ .result_len = 128,
+};
struct event_crypto_adapter_test_params {
struct rte_mempool *mbuf_pool;
struct rte_mempool *op_mpool;
+ struct rte_mempool *asym_op_mpool;
struct rte_mempool *session_mpool;
struct rte_mempool *session_priv_mpool;
+ struct rte_mempool *asym_sess_mpool;
struct rte_cryptodev_config *config;
uint8_t crypto_event_port_id;
uint8_t internal_port_op_fwd;
@@ -134,11 +220,24 @@ send_recv_ev(struct rte_event *ev)
rte_pause();
op = recv_ev.event_ptr;
+ if (op->type == RTE_CRYPTO_OP_TYPE_SY
[PATCH v4 7/7] test-eventdev: support asym ops for crypto adapter
Test eventdev app is updated to add new option for asymmetric
crypto ops for event crypto adapter.
Signed-off-by: Akhil Goyal
Acked-by: Fan Zhang
Acked-by: Abhinandan Gujjar
---
app/test-eventdev/evt_common.h | 2 +
app/test-eventdev/evt_options.c | 17 ++
app/test-eventdev/evt_options.h | 4 +
app/test-eventdev/test_perf_atq.c| 12 +-
app/test-eventdev/test_perf_common.c | 250 +++
app/test-eventdev/test_perf_common.h | 45 +++--
app/test-eventdev/test_perf_queue.c | 12 +-
doc/guides/tools/testeventdev.rst| 5 +
8 files changed, 284 insertions(+), 63 deletions(-)
diff --git a/app/test-eventdev/evt_common.h b/app/test-eventdev/evt_common.h
index 2f301a7e79..196eca8bd0 100644
--- a/app/test-eventdev/evt_common.h
+++ b/app/test-eventdev/evt_common.h
@@ -6,6 +6,7 @@
#define _EVT_COMMON_
#include
+#include
#include
#include
#include
@@ -80,6 +81,7 @@ struct evt_options {
uint64_t optm_timer_tick_nsec;
enum evt_prod_type prod_type;
enum rte_event_crypto_adapter_mode crypto_adptr_mode;
+ enum rte_crypto_op_type crypto_op_type;
};
static inline bool
diff --git a/app/test-eventdev/evt_options.c b/app/test-eventdev/evt_options.c
index d3c704d2b3..8326734b64 100644
--- a/app/test-eventdev/evt_options.c
+++ b/app/test-eventdev/evt_options.c
@@ -38,6 +38,7 @@ evt_options_default(struct evt_options *opt)
opt->eth_queues = 1;
opt->vector_size = 64;
opt->vector_tmo_nsec = 100E3;
+ opt->crypto_op_type = RTE_CRYPTO_OP_TYPE_SYMMETRIC;
}
typedef int (*option_parser_t)(struct evt_options *opt,
@@ -142,6 +143,18 @@ evt_parse_crypto_adptr_mode(struct evt_options *opt, const
char *arg)
return ret;
}
+static int
+evt_parse_crypto_op_type(struct evt_options *opt, const char *arg)
+{
+ uint8_t op_type;
+ int ret;
+
+ ret = parser_read_uint8(&op_type, arg);
+ opt->crypto_op_type = op_type ? RTE_CRYPTO_OP_TYPE_ASYMMETRIC :
+ RTE_CRYPTO_OP_TYPE_SYMMETRIC;
+ return ret;
+}
+
static int
evt_parse_test_name(struct evt_options *opt, const char *arg)
{
@@ -368,6 +381,8 @@ usage(char *program)
"\t--expiry_nsec : event timer expiry ns.\n"
"\t--crypto_adptr_mode : 0 for OP_NEW mode (default) and\n"
"\t 1 for OP_FORWARD mode.\n"
+ "\t--crypto_op_type : 0 for SYM ops (default) and\n"
+ "\t 1 for ASYM ops.\n"
"\t--mbuf_sz : packet mbuf size.\n"
"\t--max_pkt_sz : max packet size.\n"
"\t--prod_enq_burst_sz : producer enqueue burst size.\n"
@@ -442,6 +457,7 @@ static struct option lgopts[] = {
{ EVT_PROD_TIMERDEV, 0, 0, 0 },
{ EVT_PROD_TIMERDEV_BURST, 0, 0, 0 },
{ EVT_CRYPTO_ADPTR_MODE, 1, 0, 0 },
+ { EVT_CRYPTO_OP_TYPE, 1, 0, 0 },
{ EVT_NB_TIMERS, 1, 0, 0 },
{ EVT_NB_TIMER_ADPTRS, 1, 0, 0 },
{ EVT_TIMER_TICK_NSEC, 1, 0, 0 },
@@ -484,6 +500,7 @@ evt_opts_parse_long(int opt_idx, struct evt_options *opt)
{ EVT_PROD_TIMERDEV, evt_parse_timer_prod_type},
{ EVT_PROD_TIMERDEV_BURST, evt_parse_timer_prod_type_burst},
{ EVT_CRYPTO_ADPTR_MODE, evt_parse_crypto_adptr_mode},
+ { EVT_CRYPTO_OP_TYPE, evt_parse_crypto_op_type},
{ EVT_NB_TIMERS, evt_parse_nb_timers},
{ EVT_NB_TIMER_ADPTRS, evt_parse_nb_timer_adptrs},
{ EVT_TIMER_TICK_NSEC, evt_parse_timer_tick_nsec},
diff --git a/app/test-eventdev/evt_options.h b/app/test-eventdev/evt_options.h
index 2231c58801..f23fb8a511 100644
--- a/app/test-eventdev/evt_options.h
+++ b/app/test-eventdev/evt_options.h
@@ -38,6 +38,7 @@
#define EVT_PROD_TIMERDEV("prod_type_timerdev")
#define EVT_PROD_TIMERDEV_BURST ("prod_type_timerdev_burst")
#define EVT_CRYPTO_ADPTR_MODE ("crypto_adptr_mode")
+#define EVT_CRYPTO_OP_TYPE ("crypto_op_type")
#define EVT_NB_TIMERS("nb_timers")
#define EVT_NB_TIMER_ADPTRS ("nb_timer_adptrs")
#define EVT_TIMER_TICK_NSEC ("timer_tick_nsec")
@@ -298,6 +299,9 @@ evt_dump_producer_type(struct evt_options *opt)
"Event crypto adapter producers");
evt_dump("crypto adapter mode", "%s",
opt->crypto_adptr_mode ? "OP_FORWARD" : "OP_NEW");
+ evt_dump("crypto op type", "%s",
+(opt->crypto_op_type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) ?
+"SYMMETRIC" : "ASYMMETRIC");
evt_dump("nb_cryptodev", "%u", rte_cryptodev_count());
break;
}
diff --git a/app/test-eventdev/test_perf_atq.c
b/app/test-eventdev/test_perf_atq.c
index 67ff681666..6a2aa86fd2 100644
--- a/app/test-eventdev/test_perf_atq.c
+++ b/app/test-eventdev/
Re: [PATCH v5] eal: add seqlock
On Sun, 1 May 2022 16:03:27 +0200
Mattias Rönnblom wrote:
> +struct data {
> + rte_seqlock_t lock;
> +
> + uint64_t a;
> + uint64_t b __rte_cache_aligned;
> + uint64_t c __rte_cache_aligned;
> +} __rte_cache_aligned;
This will end up taking 192 bytes per lock.
Which is a lot especially if embedded in another structure.
回复: [PATCH v1 3/5] ethdev: add API for direct rearm mode
> -邮件原件- > 发件人: Jerin Jacob > 发送时间: Wednesday, April 20, 2022 6:50 PM > 收件人: Feifei Wang > 抄送: tho...@monjalon.net; Ferruh Yigit ; Andrew > Rybchenko ; Ray Kinsella > ; dpdk-dev ; nd ; > Honnappa Nagarahalli ; Ruifeng Wang > > 主题: Re: [PATCH v1 3/5] ethdev: add API for direct rearm mode > > On Wed, Apr 20, 2022 at 1:47 PM Feifei Wang > wrote: > > > > Add API for enabling direct rearm mode and for mapping RX and TX > > queues. Currently, the API supports 1:1(txq : rxq) mapping. > > > > Suggested-by: Honnappa Nagarahalli > > Signed-off-by: Feifei Wang > > Reviewed-by: Ruifeng Wang > > Reviewed-by: Honnappa Nagarahalli > > --- > > > + * > > + * @return > > + * - (0) if successful. > > + */ > > +__rte_experimental > > +int rte_eth_direct_rxrearm_map(uint16_t rx_port_id, uint16_t > rx_queue_id, > > + uint16_t tx_port_id, uint16_t > > +tx_queue_id); > > Won't existing rte_eth_hairpin_* APIs work to achieve the same? [Feifei] Thanks for the comment. Look at the hairpin feature which is enabled in MLX5 driver. I think the most important difference is that hairpin just re-directs the packet from the Rx queue to Tx queue in the same port, and Rx/Tx queue just can record the peer queue id. For direct rearm, it can map Rx queue to the Tx queue which are from different ports. And this needs Rx queue records paired port id and queue id. Furthermore, hairpin needs to set up new hairpin queue and then it can bind Rx queue to Tx queue. and direct-rearm just can use normal queue to map. This is due to direct rearm needs used buffers and it doesn't care about packet.
RE: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper
Hi Jerin, > > For case two(host shaper), I think we can't use RX meter, because > > it's > actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia > BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have > two terms here: Host-system stands for the system the BF2 NIC is inserted; > ARM-system stands for the embedded ARM in BF2. ARM-system is doing the > forwarding. This is the way host shaper works: we configure the register on > ARM-system, but it affects Host-system's TX shaper, which means the > shaper is working on the remote port, it's not a RX meter concept, hence we > can't use DPDK RX meter framework. I'd suggest to still use private API. > > OK. If the host is using the DPDK application then rte_tm can be used on the > egress side to enable the same. If it is not DPDK, then yes, we need private > APIs. I see your point. The RX drop happens on ARM-system, it'll be too late to notify Host-system to reduce traffic rate. To achieve dropless, MLX developed this feature to configure host shaper on remote port. The Host-system is flexible, it may use DPDK or not. Regards, Spike. > -Original Message- > From: Jerin Jacob > Sent: Sunday, May 1, 2022 8:51 PM > To: Spike Du > Cc: Andrew Rybchenko ; Cristian > Dumitrescu ; Ferruh Yigit > ; techbo...@dpdk.org; Matan Azrad > ; Slava Ovsiienko ; Ori Kam > ; NBU-Contact-Thomas Monjalon (EXTERNAL) > ; dpdk-dev ; Raslan Darawsheh > > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > External email: Use caution opening links or attachments > > > On Tue, Apr 26, 2022 at 8:12 AM Spike Du wrote: > > > > Hi Jerin, > > Hi Spike, > > > Thanks for your comments and sorry for the late response. > > > > For case one, I think I can refine the design and add LWM(limit > watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. > > OK. > > > > > For case two(host shaper), I think we can't use RX meter, because > > it's > actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia > BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have > two terms here: Host-system stands for the system the BF2 NIC is inserted; > ARM-system stands for the embedded ARM in BF2. ARM-system is doing the > forwarding. This is the way host shaper works: we configure the register on > ARM-system, but it affects Host-system's TX shaper, which means the > shaper is working on the remote port, it's not a RX meter concept, hence we > can't use DPDK RX meter framework. I'd suggest to still use private API. > > OK. If the host is using the DPDK application then rte_tm can be used on the > egress side to enable the same. If it is not DPDK, then yes, we need private > APIs. > > > > > For testpmd part, I understand your concern. Because we need one > private API for host shaper, and we need testpmd's forwarding code to show > how it works to user, we need to call the private API in testpmd. If current > patch is not acceptable, what's the correct way to do it? Any framework to > isolate the PMD private logic from testpmd common code, but still give a > chance to call private APIs in testpmd? > > Please check "PMD API" item in > http://mails.dpdk.org/archives/dev/2022-April/239191.html > > > > > > > Regards, > > Spike. > > > > > > > > > -Original Message- > > > From: Jerin Jacob > > > Sent: Tuesday, April 5, 2022 4:59 PM > > > To: Spike Du ; Andrew Rybchenko > > > ; Cristian Dumitrescu > > > ; Ferruh Yigit > > > ; techbo...@dpdk.org > > > Cc: Matan Azrad ; Slava Ovsiienko > > > ; Ori Kam ; NBU-Contact- > > > Thomas Monjalon (EXTERNAL) ; dpdk-dev > > > ; Raslan Darawsheh > > > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host > > > shaper > > > > > > External email: Use caution opening links or attachments > > > > > > > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du wrote: > > > > > > > > LWM(limit watermark) is per RX queue attribute, when RX queue > > > > fullness reach the LWM limit, HW sends an event to dpdk application. > > > > Host shaper can configure shaper rate and lwm-triggered for a host port. > > > > The shaper limits the rate of traffic from host port to wire port. > > > > If lwm-triggered is enabled, a 100Mbps shaper is enabled > > > > automatically when one of the host port's Rx queues receives LWM > event. > > > > > > > > These two features can combine to control traffic from host port > > > > to wire > > > port. > > > > The work flow is configure LWM to RX queue and enable > > > > lwm-triggered flag in host shaper, after receiving LWM event, > > > > delay a while until RX queue is empty , then disable the shaper. > > > > We recycle this work flow to > > > reduce RX queue drops. > > > > > > > > Spike Du (6): > > > > net/mlx5: add LWM support for Rxq > > > > common/mlx5: share interrupt management > > > > net/mlx5: add LWM event handling support > > > > net/
Re: [PATCH v5] eal: add seqlock
On 2022-05-01 22:17, Stephen Hemminger wrote:
> On Sun, 1 May 2022 16:03:27 +0200
> Mattias Rönnblom wrote:
>
>> +struct data {
>> +rte_seqlock_t lock;
>> +
>> +uint64_t a;
>> +uint64_t b __rte_cache_aligned;
>> +uint64_t c __rte_cache_aligned;
>> +} __rte_cache_aligned;
>
> This will end up taking 192 bytes per lock.
> Which is a lot especially if embedded in another structure.
"b" and "c" are cache-line aligned to increase the chance of exposing
any bugs in the seqlock implementation. With these annotations,
accessing all struct data's fields are multiple distinct interactions
with the memory hierarchy, instead of one atomic "request for ownership"
type operation for a particular cache line, from the core. At least that
what the difference would be in my simple mental model of the typical CPU.
You mention this because you think it serves as a bad example, or what
is the reason? The lock itself is much smaller than that, and not
cache-line aligned. "struct data" are only used by the unit tests.
I should have mentioned the reason for the __rte_cache_aligned as a comment.
Re: [PATCH v5] eal: add seqlock
On Sun, May 1, 2022 at 4:22 PM Mattias Rönnblom wrote: > > On 2022-05-01 16:03, Mattias Rönnblom wrote: > > A sequence lock (seqlock) is synchronization primitive which allows > > "/../ is a /../" > > > > David, maybe you can fix this typo? Unless there is a need for a new > version. Noted. No need for a new version just for this. Thanks. -- David Marchand
