* [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-24 12:43 [dpdk-dev] [v2,0/6] eventdev: cover letter - crypto adapter Abhinandan Gujjar
@ 2018-04-24 12:43 ` Abhinandan Gujjar
2018-04-25 12:42 ` Akhil Goyal
2018-04-29 16:08 ` Jerin Jacob
2018-04-24 12:43 ` [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for " Abhinandan Gujjar
` (4 subsequent siblings)
5 siblings, 2 replies; 29+ messages in thread
From: Abhinandan Gujjar @ 2018-04-24 12:43 UTC (permalink / raw)
To: jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, abhinandan.gujjar, nikhil.rao, gage.eads
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_eventdev/rte_event_crypto_adapter.h | 532 +++++++++++++++++++++++++
1 file changed, 532 insertions(+)
create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h b/lib/librte_eventdev/rte_event_crypto_adapter.h
new file mode 100644
index 0000000..aa4f32c
--- /dev/null
+++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
@@ -0,0 +1,532 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2017-2018 Intel Corporation
+ */
+
+#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
+#define _RTE_EVENT_CRYPTO_ADAPTER_
+
+/**
+ * @file
+ *
+ * RTE Event crypto adapter
+ *
+ * Eventdev library provides couple of adapters to bridge between various
+ * components for providing new event source. The event crypto adapter is
+ * one of those adapter which is intended to bridge between event devices
+ * and crypto devices.
+ *
+ * The crypto adapter adds support to enqueue/dequeue crypto operations to/
+ * from event device. The packet flow between crypto device and the event
+ * device can be accomplished using both SW and HW based transfer mechanisms.
+ * The adapter uses an EAL service core function for SW based packet transfer
+ * and uses the eventdev PMD functions to configure HW based packet transfer
+ * between the crypto device and the event device.
+ *
+ * The application can choose to submit a crypto operation directly to
+ * crypto device or send it to the crypto adapter via eventdev, the crypto
+ * adapter then submits the crypto operation to the crypto device.
+ * The first mode is known as the dequeue only (DEQ_ONLY) mode and the
+ * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode can
+ * be specified while creating the adapter.
+ *
+ *
+ * Working model of DEQ_ONLY mode:
+ * ===============================
+ *
+ * +--------------+ +--------------+
+ * Events | | | Crypto stage |
+ * <------>| Event device |-------->| + enqueue to |
+ * | | | cryptodev |
+ * +--------------+ +--------------+
+ * event ^ |
+ * enqueue| | crypto
+ * | v enqueue
+ * +--------------+ +--------------+
+ * | | | |
+ * |Crypto adapter|<--------| Cryptodev |
+ * | | | |
+ * +--------------+ +--------------+
+ *
+ * In the DEQ_ONLY mode, application submits crypto operations directly to
+ * crypto device. The adapter then dequeues crypto completions from crypto
+ * device and enqueue events to the event device.
+ * In this mode, application needs to specify event information (response
+ * information) which is needed to enqueue an event after the crypto operation
+ * is completed.
+ *
+ *
+ * Working model of ENQ_DEQ mode:
+ * ==============================
+ *
+ * +--------------+ +--------------+
+ * Events | | | |
+ * <------>| Event device |-------->| Crypto stage |
+ * | | | |
+ * +--------------+ +--------------+
+ * event ^ |
+ * enqueue| | event
+ * | v dequeue
+ * +---------------------------------------+
+ * | |
+ * | Crypto adapter |
+ * | |
+ * +---------------------------------------+
+ * ^
+ * | crypto
+ * | enq/deq
+ * v
+ * +-------------+
+ * | |
+ * | Cryptodev |
+ * | |
+ * +-------------+
+ *
+ * In the ENQ_DEQ mode, application sends crypto operations as events to
+ * the adapter which dequeues events and perform cryptodev operations.
+ * The adapter dequeues crypto completions from cryptodev and enqueue
+ * events to the event device.
+ * In this mode, the application needs to specify the cryptodev ID
+ * and queue pair ID (request information) needed to enqueue a crypto
+ * operation in addition to the event information (response information)
+ * needed to enqueue an event after the crypto operation has completed.
+ *
+ *
+ * The event crypto adapter provides common APIs to configure the packet flow
+ * from the crypto device to event devices for both SW and HW based transfers.
+ * The crypto event adapter's functions are:
+ * - rte_event_crypto_adapter_create_ext()
+ * - rte_event_crypto_adapter_create()
+ * - rte_event_crypto_adapter_free()
+ * - rte_event_crypto_adapter_queue_pair_add()
+ * - rte_event_crypto_adapter_queue_pair_del()
+ * - rte_event_crypto_adapter_start()
+ * - rte_event_crypto_adapter_stop()
+ * - rte_event_crypto_adapter_stats_get()
+ * - rte_event_crypto_adapter_stats_reset()
+
+ * The applicaton creates an instance using rte_event_crypto_adapter_create()
+ * or rte_event_crypto_adapter_create_ext().
+ *
+ * Cryptodev queue pair addition/deletion is done using the
+ * rte_event_crypto_adapter_queue_pair_xxx() APIs.
+ *
+ * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide whether
+ * request/response(private) data is located in the crypto/security session
+ * or at an offset in the rte_crypto_op.
+ * The rte_crypto_op::private_data_offset provides an offset to locate the
+ * request/response information in the rte_crypto_op.
+ *
+ * For session-based operations, the set and get API provides a mechanism for
+ * an application to store and retrieve the data information stored
+ * along with the crypto session.
+
+ * For session-less mode, the adapter gets the private data information placed
+ * along with the ``struct rte_crypto_op``.
+ * The ``rte_crypto_op::private_data_offset`` indicates the start of private
+ * data information. The offset is counted from the start of the rte_crypto_op
+ * including initialization vector (IV).
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <stdint.h>
+
+#include "rte_eventdev.h"
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this enum may change without prior notice
+ *
+ * Crypto event adapter mode
+ */
+enum rte_event_crypto_adapter_mode {
+ RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
+ /**< Start only dequeue part of crypto adapter.
+ * Application submits crypto requests to the cryptodev.
+ * Adapter only dequeues the crypto completions from cryptodev
+ * and enqueue events to the eventdev.
+ */
+ RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
+ /**< Start both enqueue & dequeue part of crypto adapter.
+ * Application submits crypto requests as events to the crypto
+ * adapter. Adapter submits crypto requests to the cryptodev
+ * and crypto completions are enqueued back to the eventdev.
+ */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Crypto event request structure will be filled by application to
+ * provide event request information to the adapter.
+ */
+struct rte_event_crypto_request {
+ uint8_t resv[8];
+ /**< Overlaps with first 8 bytes of struct rte_event
+ * that encode the response event information
+ */
+ uint16_t cdev_id;
+ /**< cryptodev ID to be used */
+ uint16_t queue_pair_id;
+ /**< cryptodev queue pair ID to be used */
+ uint32_t resv1;
+ /**< Reserved bits */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Crypto event metadata structure will be filled by application
+ * to provide crypto request and event response information.
+ *
+ * If crypto events are enqueued using a HW mechanism, the cryptodev
+ * PMD will use the event response information to set up the event
+ * that is enqueued back to eventdev after completion of the crypto
+ * operation. If the transfer is done by SW, event response information
+ * will be used by the adapter.
+ */
+union rte_event_crypto_metadata {
+ struct rte_event_crypto_request request_info;
+ struct rte_event response_info;
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Adapter configuration structure that the adapter configuration callback
+ * function is expected to fill out
+ * @see rte_event_crypto_adapter_conf_cb
+ */
+struct rte_event_crypto_adapter_conf {
+ uint8_t event_port_id;
+ /**< Event port identifier, the adapter enqueues events to this
+ * port and also dequeues crypto request events in ENQ_DEQ mode.
+ */
+ uint32_t max_nb;
+ /**< The adapter can return early if it has processed at least
+ * max_nb crypto ops. This isn't treated as a requirement; batching
+ * may cause the adapter to process more than max_nb crypto ops.
+ */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Function type used for adapter configuration callback. The callback is
+ * used to fill in members of the struct rte_event_crypto_adapter_conf, this
+ * callback is invoked when creating a SW service for packet transfer from
+ * cryptodev queue pair to the event device. The SW service is created within
+ * the rte_event_crypto_adapter_queue_pair_add() function if SW based packet
+ * transfers from cryptodev queue pair to the event device are required.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param dev_id
+ * Event device identifier.
+ *
+ * @param conf
+ * Structure that needs to be populated by this callback.
+ *
+ * @param arg
+ * Argument to the callback. This is the same as the conf_arg passed to the
+ * rte_event_crypto_adapter_create_ext().
+ */
+typedef int (*rte_event_crypto_adapter_conf_cb) (uint8_t id, uint8_t dev_id,
+ struct rte_event_crypto_adapter_conf *conf,
+ void *arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Queue pair configuration structure containing event information.
+ * @see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
+ */
+struct rte_event_crypto_queue_pair_conf {
+ struct rte_event ev;
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * A structure used to retrieve statistics for an event crypto adapter
+ * instance.
+ */
+
+struct rte_event_crypto_adapter_stats {
+ uint64_t event_poll_count;
+ /**< Event port poll count */
+ uint64_t event_dequeue_count;
+ /**< Event dequeue count */
+ uint64_t crypto_enq_count;
+ /**< Cryptodev enqueue count */
+ uint64_t crypto_enq_fail;
+ /**< Cryptodev enqueue failed count */
+ uint64_t crypto_deq_count;
+ /**< Cryptodev dequeue count */
+ uint64_t event_enqueue_count;
+ /**< Event enqueue count */
+ uint64_t event_enq_retry_count;
+ /**< Event enqueue retry count */
+ uint64_t event_enq_fail_count;
+ /**< Event enqueue fail count */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Create a new event crypto adapter with the specified identifier.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param dev_id
+ * Event device identifier.
+ *
+ * @param conf_cb
+ * Callback function that fills in members of a
+ * struct rte_event_crypto_adapter_conf struct passed into
+ * it.
+ *
+ * @param mode
+ * Flag to indicate to start dequeue only or both enqueue & dequeue.
+ *
+ * @param conf_arg
+ * Argument that is passed to the conf_cb function.
+ *
+ * @return
+ * - 0: Success
+ * - <0: Error code on failure
+ */
+int __rte_experimental
+rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id,
+ rte_event_crypto_adapter_conf_cb conf_cb,
+ enum rte_event_crypto_adapter_mode mode,
+ void *conf_arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Create a new event crypto adapter with the specified identifier.
+ * This function uses an internal configuration function that creates an event
+ * port. This default function reconfigures the event device with an
+ * additional event port and setups up the event port using the port_config
+ * parameter passed into this function. In case the application needs more
+ * control in configuration of the service, it should use the
+ * rte_event_crypto_adapter_create_ext() version.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param dev_id
+ * Event device identifier.
+ *
+ * @param port_config
+ * Argument of type *rte_event_port_conf* that is passed to the conf_cb
+ * function.
+ *
+ * @param mode
+ * Flag to indicate to start dequeue only or both enqueue & dequeue.
+ *
+ * @return
+ * - 0: Success
+ * - <0: Error code on failure
+ */
+int __rte_experimental
+rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
+ struct rte_event_port_conf *port_config,
+ enum rte_event_crypto_adapter_mode mode);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Free an event crypto adapter
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @return
+ * - 0: Success
+ * - <0: Error code on failure, If the adapter still has queue pairs
+ * added to it, the function returns -EBUSY.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_free(uint8_t id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Add a queue pair to an event crypto adapter.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param cdev_id
+ * Cryptodev identifier.
+ *
+ * @param queue_pair_id
+ * Cryptodev queue pair identifier. If queue_pair_id is set -1,
+ * adapter adds all the pre configured queue pairs to the instance.
+ *
+ * @param conf
+ * Additional configuration structure of type
+ * *rte_event_crypto_queue_pair_conf*
+ *
+ * @return
+ * - 0: Success, Receive queue pair added correctly.
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_queue_pair_add(uint8_t id,
+ uint8_t cdev_id,
+ int32_t queue_pair_id,
+ const struct rte_event_crypto_queue_pair_conf *conf);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Delete a queue pair from an event crypto adapter.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param cdev_id
+ * Cryptodev identifier.
+ *
+ * @param queue_pair_id
+ * Cryptodev queue pair identifier.
+ *
+ * @return
+ * - 0: Success, queue pair deleted successfully.
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_queue_pair_del(uint8_t id, uint8_t cdev_id,
+ int32_t queue_pair_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Start event crypto adapter
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ *
+ * @return
+ * - 0: Success, Adapter started successfully.
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_start(uint8_t id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Stop event crypto adapter
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @return
+ * - 0: Success, Adapter stopped successfully.
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_stop(uint8_t id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve statistics for an adapter
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param [out] stats
+ * A pointer to structure used to retrieve statistics for an adapter.
+ *
+ * @return
+ * - 0: Success, retrieved successfully.
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_stats_get(uint8_t id,
+ struct rte_event_crypto_adapter_stats *stats);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Reset statistics for an adapter.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @return
+ * - 0: Success, statistics reset successfully.
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_stats_reset(uint8_t id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the service ID of an adapter. If the adapter doesn't use
+ * a rte_service function, this function returns -ESRCH.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param [out] service_id
+ * A pointer to a uint32_t, to be filled in with the service id.
+ *
+ * @return
+ * - 0: Success
+ * - <0: Error code on failure, if the adapter doesn't use a rte_service
+ * function, this function returns -ESRCH.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_service_id_get(uint8_t id, uint32_t *service_id);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the event port of an adapter.
+ *
+ * @param id
+ * Adapter identifier.
+ *
+ * @param [out] event_port_id
+ * Event port identifier used to link to the queue used in ENQ_DEQ mode.
+ *
+ * @return
+ * - 0: Success
+ * - <0: Error code on failure.
+ */
+int __rte_experimental
+rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t *event_port_id);
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* _RTE_EVENT_CRYPTO_ADAPTER_ */
--
1.9.1
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-24 12:43 ` [dpdk-dev] [v2,1/6] eventdev: introduce event " Abhinandan Gujjar
@ 2018-04-25 12:42 ` Akhil Goyal
2018-04-26 6:07 ` Gujjar, Abhinandan S
2018-04-29 16:08 ` Jerin Jacob
1 sibling, 1 reply; 29+ messages in thread
From: Akhil Goyal @ 2018-04-25 12:42 UTC (permalink / raw)
To: Abhinandan Gujjar, jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, nikhil.rao, gage.eads
Hi Abhinandan,
On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> lib/librte_eventdev/rte_event_crypto_adapter.h | 532 +++++++++++++++++++++++++
> 1 file changed, 532 insertions(+)
> create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
>
> diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h b/lib/librte_eventdev/rte_event_crypto_adapter.h
> new file mode 100644
> index 0000000..aa4f32c
> --- /dev/null
> +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> @@ -0,0 +1,532 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2017-2018 Intel Corporation
> + */
> +
> +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> +#define _RTE_EVENT_CRYPTO_ADAPTER_
> +
> +/**
> + * @file
> + *
> + * RTE Event crypto adapter
> + *
> + * Eventdev library provides couple of adapters to bridge between various
> + * components for providing new event source. The event crypto adapter is
> + * one of those adapter which is intended to bridge between event devices
> + * and crypto devices.
> + *
> + * The crypto adapter adds support to enqueue/dequeue crypto operations to/
> + * from event device. The packet flow between crypto device and the event
> + * device can be accomplished using both SW and HW based transfer mechanisms.
> + * The adapter uses an EAL service core function for SW based packet transfer
> + * and uses the eventdev PMD functions to configure HW based packet transfer
> + * between the crypto device and the event device.
> + *
> + * The application can choose to submit a crypto operation directly to
> + * crypto device or send it to the crypto adapter via eventdev, the crypto
> + * adapter then submits the crypto operation to the crypto device.
> + * The first mode is known as the dequeue only (DEQ_ONLY) mode and the
> + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode can
> + * be specified while creating the adapter.
> + *
> + *
> + * Working model of DEQ_ONLY mode:
> + * ===============================
> + *
> + * +--------------+ +--------------+
> + * Events | | | Crypto stage |
> + * <------>| Event device |-------->| + enqueue to |
> + * | | | cryptodev |
> + * +--------------+ +--------------+
> + * event ^ |
> + * enqueue| | crypto
> + * | v enqueue
> + * +--------------+ +--------------+
> + * | | | |
> + * |Crypto adapter|<--------| Cryptodev |
> + * | | | |
> + * +--------------+ +--------------+
> + *
The diagram looks a bit cryptic. Enqueue to cryptodev will be done from
application and not from event device. The arrow from event device to
crypto stage is not clear. And application dequeues events from event
device. So that should not be bidirectional arrow.
> + * In the DEQ_ONLY mode, application submits crypto operations directly to
> + * crypto device. The adapter then dequeues crypto completions from crypto
> + * device and enqueue events to the event device.
> + * In this mode, application needs to specify event information (response
> + * information) which is needed to enqueue an event after the crypto operation
> + * is completed.
> + *
> + *
> + * Working model of ENQ_DEQ mode:
> + * ==============================
> + *
> + * +--------------+ +--------------+
> + * Events | | | |
> + * <------>| Event device |-------->| Crypto stage |
> + * | | | |
> + * +--------------+ +--------------+
> + * event ^ |
> + * enqueue| | event
> + * | v dequeue
> + * +---------------------------------------+
> + * | |
> + * | Crypto adapter |
> + * | |
> + * +---------------------------------------+
> + * ^
> + * | crypto
> + * | enq/deq
> + * v
> + * +-------------+
> + * | |
> + * | Cryptodev |
> + * | |
> + * +-------------+
> + *
> + * In the ENQ_DEQ mode, application sends crypto operations as events to
> + * the adapter which dequeues events and perform cryptodev operations.
> + * The adapter dequeues crypto completions from cryptodev and enqueue
> + * events to the event device.
> + * In this mode, the application needs to specify the cryptodev ID
> + * and queue pair ID (request information) needed to enqueue a crypto
> + * operation in addition to the event information (response information)
> + * needed to enqueue an event after the crypto operation has completed.
> + *
> + *
> + * The event crypto adapter provides common APIs to configure the packet flow
> + * from the crypto device to event devices for both SW and HW based transfers.
> + * The crypto event adapter's functions are:
> + * - rte_event_crypto_adapter_create_ext()
> + * - rte_event_crypto_adapter_create()
> + * - rte_event_crypto_adapter_free()
> + * - rte_event_crypto_adapter_queue_pair_add()
> + * - rte_event_crypto_adapter_queue_pair_del()
> + * - rte_event_crypto_adapter_start()
> + * - rte_event_crypto_adapter_stop()
> + * - rte_event_crypto_adapter_stats_get()
> + * - rte_event_crypto_adapter_stats_reset()
> +
> + * The applicaton creates an instance using rte_event_crypto_adapter_create()
application spell check.
> + * or rte_event_crypto_adapter_create_ext().
> + *
> + * Cryptodev queue pair addition/deletion is done using the
> + * rte_event_crypto_adapter_queue_pair_xxx() APIs.
> + *
> + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide whether
> + * request/response(private) data is located in the crypto/security session
> + * or at an offset in the rte_crypto_op.
> + * The rte_crypto_op::private_data_offset provides an offset to locate the
> + * request/response information in the rte_crypto_op.
Above line is repeated below. This one can be removed.
> + *
> + * For session-based operations, the set and get API provides a mechanism for
> + * an application to store and retrieve the data information stored
> + * along with the crypto session.
> +
> + * For session-less mode, the adapter gets the private data information placed
> + * along with the ``struct rte_crypto_op``.
> + * The ``rte_crypto_op::private_data_offset`` indicates the start of private
> + * data information. The offset is counted from the start of the rte_crypto_op
> + * including initialization vector (IV).
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <stdint.h>
> +
> +#include "rte_eventdev.h"
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this enum may change without prior notice
> + *
> + * Crypto event adapter mode
> + */
> +enum rte_event_crypto_adapter_mode {
> + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
> + /**< Start only dequeue part of crypto adapter.
> + * Application submits crypto requests to the cryptodev.
> + * Adapter only dequeues the crypto completions from cryptodev
> + * and enqueue events to the eventdev.
> + */
> + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
> + /**< Start both enqueue & dequeue part of crypto adapter.
> + * Application submits crypto requests as events to the crypto
> + * adapter. Adapter submits crypto requests to the cryptodev
> + * and crypto completions are enqueued back to the eventdev.
> + */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Crypto event request structure will be filled by application to
> + * provide event request information to the adapter.
> + */
> +struct rte_event_crypto_request {
> + uint8_t resv[8];
> + /**< Overlaps with first 8 bytes of struct rte_event
> + * that encode the response event information
> + */
I think in case of ENQ_DEQ mode, both request and response info is
required. I think it would be better to have a single structure as
struct rte_event_crypto_metadata {
struct rte_event ev;
uint16_t cdev_id;
uint16_t queue_pair_id;
uint32_t resv1;
};
The last 3 fields need not be filled by application for DEQ_ONLY mode.
Application will not get confused with request/response structures when
we have response info already present in request structure.
Or if you still insist to have separate structure for request and
response then it would be better to have it as struct instead of union
for metadata and remove the resv[8].
IMO, first one is better.
> + uint16_t cdev_id;
> + /**< cryptodev ID to be used */
> + uint16_t queue_pair_id;
> + /**< cryptodev queue pair ID to be used */
> + uint32_t resv1;
> + /**< Reserved bits */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Crypto event metadata structure will be filled by application
> + * to provide crypto request and event response information.
> + *
> + * If crypto events are enqueued using a HW mechanism, the cryptodev
> + * PMD will use the event response information to set up the event
> + * that is enqueued back to eventdev after completion of the crypto
> + * operation. If the transfer is done by SW, event response information
> + * will be used by the adapter.
> + */
> +union rte_event_crypto_metadata {
> + struct rte_event_crypto_request request_info;
> + struct rte_event response_info;
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Adapter configuration structure that the adapter configuration callback
> + * function is expected to fill out
> + * @see rte_event_crypto_adapter_conf_cb
> + */
> +struct rte_event_crypto_adapter_conf {
> + uint8_t event_port_id;
> + /**< Event port identifier, the adapter enqueues events to this
> + * port and also dequeues crypto request events in ENQ_DEQ mode.
> + */
> + uint32_t max_nb;
> + /**< The adapter can return early if it has processed at least
> + * max_nb crypto ops. This isn't treated as a requirement; batching
> + * may cause the adapter to process more than max_nb crypto ops.
> + */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Function type used for adapter configuration callback. The callback is
> + * used to fill in members of the struct rte_event_crypto_adapter_conf, this
> + * callback is invoked when creating a SW service for packet transfer from
> + * cryptodev queue pair to the event device. The SW service is created within
> + * the rte_event_crypto_adapter_queue_pair_add() function if SW based packet
> + * transfers from cryptodev queue pair to the event device are required.
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @param dev_id
> + * Event device identifier.
> + *
> + * @param conf
> + * Structure that needs to be populated by this callback.
> + *
> + * @param arg
> + * Argument to the callback. This is the same as the conf_arg passed to the
> + * rte_event_crypto_adapter_create_ext().
> + */
> +typedef int (*rte_event_crypto_adapter_conf_cb) (uint8_t id, uint8_t dev_id,
> + struct rte_event_crypto_adapter_conf *conf,
> + void *arg);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Queue pair configuration structure containing event information.
> + * @see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
> + */
> +struct rte_event_crypto_queue_pair_conf {
> + struct rte_event ev;
> +};
We may not need this wrapper structure. We can directly use rte_event.
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * A structure used to retrieve statistics for an event crypto adapter
> + * instance.
> + */
> +
> +struct rte_event_crypto_adapter_stats {
> + uint64_t event_poll_count;
> + /**< Event port poll count */
> + uint64_t event_dequeue_count;
better to use uniform naming. event_deq_count
> + /**< Event dequeue count */
> + uint64_t crypto_enq_count;
> + /**< Cryptodev enqueue count */
> + uint64_t crypto_enq_fail;
> + /**< Cryptodev enqueue failed count */
> + uint64_t crypto_deq_count;
> + /**< Cryptodev dequeue count */
> + uint64_t event_enqueue_count;
event_enq_count
> + /**< Event enqueue count */
> + uint64_t event_enq_retry_count;
> + /**< Event enqueue retry count */
> + uint64_t event_enq_fail_count;
> + /**< Event enqueue fail count */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Create a new event crypto adapter with the specified identifier.
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @param dev_id
> + * Event device identifier.
> + *
> + * @param conf_cb
> + * Callback function that fills in members of a
> + * struct rte_event_crypto_adapter_conf struct passed into
> + * it.
> + *
> + * @param mode
> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> + *
> + * @param conf_arg
> + * Argument that is passed to the conf_cb function.
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure
> + */
> +int __rte_experimental
> +rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id,
> + rte_event_crypto_adapter_conf_cb conf_cb,
> + enum rte_event_crypto_adapter_mode mode,
> + void *conf_arg);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Create a new event crypto adapter with the specified identifier.
> + * This function uses an internal configuration function that creates an event
> + * port. This default function reconfigures the event device with an
> + * additional event port and setups up the event port using the port_config
set up
> + * parameter passed into this function. In case the application needs more
> + * control in configuration of the service, it should use the
> + * rte_event_crypto_adapter_create_ext() version.
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @param dev_id
> + * Event device identifier.
> + *
> + * @param port_config
> + * Argument of type *rte_event_port_conf* that is passed to the conf_cb
> + * function.
> + *
> + * @param mode
> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure
> + */
> +int __rte_experimental
> +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
> + struct rte_event_port_conf *port_config,
> + enum rte_event_crypto_adapter_mode mode);
> +
[..snip..]
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Retrieve the event port of an adapter.
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @param [out] event_port_id
> + * Event port identifier used to link to the queue used in ENQ_DEQ mode.
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure.
> + */
> +int __rte_experimental
> +rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t *event_port_id);
IIUC, crypto adapter can give packets to multiple event ports.
Also, I don't see similar API in eth_rx_adapter.
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +#endif /* _RTE_EVENT_CRYPTO_ADAPTER_ */
>
Regards,
Akhil
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-25 12:42 ` Akhil Goyal
@ 2018-04-26 6:07 ` Gujjar, Abhinandan S
2018-04-26 7:16 ` Akhil Goyal
0 siblings, 1 reply; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-26 6:07 UTC (permalink / raw)
To: Akhil Goyal, jerin.jacob, hemant.agrawal, dev
Cc: Vangati, Narender, Rao, Nikhil, Eads, Gage
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, April 25, 2018 6:12 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com;
> akhil.goyal@nxp.com; dev@dpdk.org
> Cc: Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>
> Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
>
> Hi Abhinandan,
> On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
> > lib/librte_eventdev/rte_event_crypto_adapter.h | 532
> > +++++++++++++++++++++++++
> > 1 file changed, 532 insertions(+)
> > create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
> >
> > diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h
> > b/lib/librte_eventdev/rte_event_crypto_adapter.h
> > new file mode 100644
> > index 0000000..aa4f32c
> > --- /dev/null
> > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> > @@ -0,0 +1,532 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2017-2018 Intel Corporation */
> > +
> > +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> > +#define _RTE_EVENT_CRYPTO_ADAPTER_
> > +
> > +/**
> > + * @file
> > + *
> > + * RTE Event crypto adapter
> > + *
> > + * Eventdev library provides couple of adapters to bridge between
> > +various
> > + * components for providing new event source. The event crypto
> > +adapter is
> > + * one of those adapter which is intended to bridge between event
> > +devices
> > + * and crypto devices.
> > + *
> > + * The crypto adapter adds support to enqueue/dequeue crypto
> > +operations to/
> > + * from event device. The packet flow between crypto device and the
> > +event
> > + * device can be accomplished using both SW and HW based transfer
> mechanisms.
> > + * The adapter uses an EAL service core function for SW based packet
> > +transfer
> > + * and uses the eventdev PMD functions to configure HW based packet
> > +transfer
> > + * between the crypto device and the event device.
> > + *
> > + * The application can choose to submit a crypto operation directly
> > +to
> > + * crypto device or send it to the crypto adapter via eventdev, the
> > +crypto
> > + * adapter then submits the crypto operation to the crypto device.
> > + * The first mode is known as the dequeue only (DEQ_ONLY) mode and
> > +the
> > + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode
> > +can
> > + * be specified while creating the adapter.
> > + *
> > + *
> > + * Working model of DEQ_ONLY mode:
> > + * ===============================
> > + *
> > + * +--------------+ +--------------+
> > + * Events | | | Crypto stage |
> > + * <------>| Event device |-------->| + enqueue to |
> > + * | | | cryptodev |
> > + * +--------------+ +--------------+
> > + * event ^ |
> > + * enqueue| | crypto
> > + * | v enqueue
> > + * +--------------+ +--------------+
> > + * | | | |
> > + * |Crypto adapter|<--------| Cryptodev |
> > + * | | | |
> > + * +--------------+ +--------------+
> > + *
> The diagram looks a bit cryptic. Enqueue to cryptodev will be done from
> application and not from event device. The arrow from event device to crypto
> stage is not clear. And application dequeues events from event device. So that
> should not be bidirectional arrow.
You are right, it is done from application. But the application will be in the crypto stage of
pipeline. Since crypto is an intermediate stage, events are first dequeued from eventdev to
find out it's a crypto stage. Then application, in the crypto stage, enqueue "rte_crypto_ops"
to cryptodev and finally adapter enqueue crypto completions as events to eventdev.
>From this point, eventdev will pass events to the next stage (may be Tx).
That's the reason behind bidirectional arrow to event device.
>
> > + * In the DEQ_ONLY mode, application submits crypto operations
> > + directly to
> > + * crypto device. The adapter then dequeues crypto completions from
> > + crypto
> > + * device and enqueue events to the event device.
> > + * In this mode, application needs to specify event information
> > + (response
> > + * information) which is needed to enqueue an event after the crypto
> > + operation
> > + * is completed.
> > + *
> > + *
> > + * Working model of ENQ_DEQ mode:
> > + * ==============================
> > + *
> > + * +--------------+ +--------------+
> > + * Events | | | |
> > + * <------>| Event device |-------->| Crypto stage |
> > + * | | | |
> > + * +--------------+ +--------------+
> > + * event ^ |
> > + * enqueue| | event
> > + * | v dequeue
> > + * +---------------------------------------+
> > + * | |
> > + * | Crypto adapter |
> > + * | |
> > + * +---------------------------------------+
> > + * ^
> > + * | crypto
> > + * | enq/deq
> > + * v
> > + * +-------------+
> > + * | |
> > + * | Cryptodev |
> > + * | |
> > + * +-------------+
> > + *
> > + * In the ENQ_DEQ mode, application sends crypto operations as events
> > + to
> > + * the adapter which dequeues events and perform cryptodev operations.
> > + * The adapter dequeues crypto completions from cryptodev and enqueue
> > + * events to the event device.
> > + * In this mode, the application needs to specify the cryptodev ID
> > + * and queue pair ID (request information) needed to enqueue a crypto
> > + * operation in addition to the event information (response
> > + information)
> > + * needed to enqueue an event after the crypto operation has completed.
> > + *
> > + *
> > + * The event crypto adapter provides common APIs to configure the
> > + packet flow
> > + * from the crypto device to event devices for both SW and HW based
> transfers.
> > + * The crypto event adapter's functions are:
> > + * - rte_event_crypto_adapter_create_ext()
> > + * - rte_event_crypto_adapter_create()
> > + * - rte_event_crypto_adapter_free()
> > + * - rte_event_crypto_adapter_queue_pair_add()
> > + * - rte_event_crypto_adapter_queue_pair_del()
> > + * - rte_event_crypto_adapter_start()
> > + * - rte_event_crypto_adapter_stop()
> > + * - rte_event_crypto_adapter_stats_get()
> > + * - rte_event_crypto_adapter_stats_reset()
> > +
> > + * The applicaton creates an instance using
> > + rte_event_crypto_adapter_create()
> application spell check.
>
> > + * or rte_event_crypto_adapter_create_ext().
> > + *
> > + * Cryptodev queue pair addition/deletion is done using the
> > + * rte_event_crypto_adapter_queue_pair_xxx() APIs.
> > + *
> > + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide
> > + whether
> > + * request/response(private) data is located in the crypto/security
> > + session
> > + * or at an offset in the rte_crypto_op.
> > + * The rte_crypto_op::private_data_offset provides an offset to
> > + locate the
> > + * request/response information in the rte_crypto_op.
> Above line is repeated below. This one can be removed.
Ok. I will combine them.
>
> > + *
> > + * For session-based operations, the set and get API provides a
> > + mechanism for
> > + * an application to store and retrieve the data information stored
> > + * along with the crypto session.
> > +
> > + * For session-less mode, the adapter gets the private data
> > + information placed
> > + * along with the ``struct rte_crypto_op``.
> > + * The ``rte_crypto_op::private_data_offset`` indicates the start of
> > + private
> > + * data information. The offset is counted from the start of the
> > + rte_crypto_op
> > + * including initialization vector (IV).
> > + */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include <stdint.h>
> > +
> > +#include "rte_eventdev.h"
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this enum may change without prior notice
> > + *
> > + * Crypto event adapter mode
> > + */
> > +enum rte_event_crypto_adapter_mode {
> > + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
> > + /**< Start only dequeue part of crypto adapter.
> > + * Application submits crypto requests to the cryptodev.
> > + * Adapter only dequeues the crypto completions from cryptodev
> > + * and enqueue events to the eventdev.
> > + */
> > + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
> > + /**< Start both enqueue & dequeue part of crypto adapter.
> > + * Application submits crypto requests as events to the crypto
> > + * adapter. Adapter submits crypto requests to the cryptodev
> > + * and crypto completions are enqueued back to the eventdev.
> > + */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Crypto event request structure will be filled by application to
> > + * provide event request information to the adapter.
> > + */
> > +struct rte_event_crypto_request {
> > + uint8_t resv[8];
> > + /**< Overlaps with first 8 bytes of struct rte_event
> > + * that encode the response event information
> > + */
> I think in case of ENQ_DEQ mode, both request and response info is required. I
> think it would be better to have a single structure as
>
> struct rte_event_crypto_metadata {
> struct rte_event ev;
> uint16_t cdev_id;
> uint16_t queue_pair_id;
> uint32_t resv1;
> };
> The last 3 fields need not be filled by application for DEQ_ONLY mode.
> Application will not get confused with request/response structures when we
> have response info already present in request structure.
> Or if you still insist to have separate structure for request and response then it
> would be better to have it as struct instead of union for metadata and remove
> the resv[8].
> IMO, first one is better.
rte_event structure itself has enough memory to hold *both request and response information*.
struct rte_event {
/** WORD0 */
union {
uint64_t event;
.
}
/** WORD1 */
union {
uint64_t u64;
.
}
}
For response only *WORD0* is used. Whereas *WORD1* is used for request!
As proposed,
+struct rte_event_crypto_request {
+ uint8_t resv[8];
+ /**< Overlaps with first 8 bytes of struct rte_event
+ * that encode the response event information
+ */
+ uint16_t cdev_id;
+ /**< cryptodev ID to be used */
+ uint16_t queue_pair_id;
+ /**< cryptodev queue pair ID to be used */
+ uint32_t resv1;
+ /**< Reserved bits */
+};
First 8 bytes are *WORD0* and rest of the information fits into *WORD1*.
+union rte_event_crypto_metadata {
+ struct rte_event_crypto_request request_info;
+ struct rte_event response_info;
+};
Request and response together into a union will allocate memory required for (WORD0+WORD1).
I hope, this clarifies all your doubt.
>
> > + uint16_t cdev_id;
> > + /**< cryptodev ID to be used */
> > + uint16_t queue_pair_id;
> > + /**< cryptodev queue pair ID to be used */
> > + uint32_t resv1;
> > + /**< Reserved bits */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Crypto event metadata structure will be filled by application
> > + * to provide crypto request and event response information.
> > + *
> > + * If crypto events are enqueued using a HW mechanism, the cryptodev
> > + * PMD will use the event response information to set up the event
> > + * that is enqueued back to eventdev after completion of the crypto
> > + * operation. If the transfer is done by SW, event response
> > +information
> > + * will be used by the adapter.
> > + */
> > +union rte_event_crypto_metadata {
> > + struct rte_event_crypto_request request_info;
> > + struct rte_event response_info;
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Adapter configuration structure that the adapter configuration
> > +callback
> > + * function is expected to fill out
> > + * @see rte_event_crypto_adapter_conf_cb */ struct
> > +rte_event_crypto_adapter_conf {
> > + uint8_t event_port_id;
> > + /**< Event port identifier, the adapter enqueues events to this
> > + * port and also dequeues crypto request events in ENQ_DEQ mode.
> > + */
> > + uint32_t max_nb;
> > + /**< The adapter can return early if it has processed at least
> > + * max_nb crypto ops. This isn't treated as a requirement; batching
> > + * may cause the adapter to process more than max_nb crypto ops.
> > + */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Function type used for adapter configuration callback. The
> > +callback is
> > + * used to fill in members of the struct
> > +rte_event_crypto_adapter_conf, this
> > + * callback is invoked when creating a SW service for packet transfer
> > +from
> > + * cryptodev queue pair to the event device. The SW service is
> > +created within
> > + * the rte_event_crypto_adapter_queue_pair_add() function if SW based
> > +packet
> > + * transfers from cryptodev queue pair to the event device are required.
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @param dev_id
> > + * Event device identifier.
> > + *
> > + * @param conf
> > + * Structure that needs to be populated by this callback.
> > + *
> > + * @param arg
> > + * Argument to the callback. This is the same as the conf_arg passed
> > +to the
> > + * rte_event_crypto_adapter_create_ext().
> > + */
> > +typedef int (*rte_event_crypto_adapter_conf_cb) (uint8_t id, uint8_t dev_id,
> > + struct rte_event_crypto_adapter_conf *conf,
> > + void *arg);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Queue pair configuration structure containing event information.
> > + * @see
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
> > + */
> > +struct rte_event_crypto_queue_pair_conf {
> > + struct rte_event ev;
> > +};
> We may not need this wrapper structure. We can directly use rte_event.
This was done keep in mind to accommodate need for any future requirement
of having a new field added to the structure along with the rte_event.
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * A structure used to retrieve statistics for an event crypto
> > +adapter
> > + * instance.
> > + */
> > +
> > +struct rte_event_crypto_adapter_stats {
> > + uint64_t event_poll_count;
> > + /**< Event port poll count */
> > + uint64_t event_dequeue_count;
> better to use uniform naming. event_deq_count
ok
> > + /**< Event dequeue count */
> > + uint64_t crypto_enq_count;
> > + /**< Cryptodev enqueue count */
> > + uint64_t crypto_enq_fail;
> > + /**< Cryptodev enqueue failed count */
> > + uint64_t crypto_deq_count;
> > + /**< Cryptodev dequeue count */
> > + uint64_t event_enqueue_count;
> event_enq_count
ok
> > + /**< Event enqueue count */
> > + uint64_t event_enq_retry_count;
> > + /**< Event enqueue retry count */
> > + uint64_t event_enq_fail_count;
> > + /**< Event enqueue fail count */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Create a new event crypto adapter with the specified identifier.
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @param dev_id
> > + * Event device identifier.
> > + *
> > + * @param conf_cb
> > + * Callback function that fills in members of a
> > + * struct rte_event_crypto_adapter_conf struct passed into
> > + * it.
> > + *
> > + * @param mode
> > + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> > + *
> > + * @param conf_arg
> > + * Argument that is passed to the conf_cb function.
> > + *
> > + * @return
> > + * - 0: Success
> > + * - <0: Error code on failure
> > + */
> > +int __rte_experimental
> > +rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id,
> > + rte_event_crypto_adapter_conf_cb conf_cb,
> > + enum rte_event_crypto_adapter_mode mode,
> > + void *conf_arg);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Create a new event crypto adapter with the specified identifier.
> > + * This function uses an internal configuration function that creates
> > +an event
> > + * port. This default function reconfigures the event device with an
> > + * additional event port and setups up the event port using the
> > +port_config
> set up
> > + * parameter passed into this function. In case the application needs
> > +more
> > + * control in configuration of the service, it should use the
> > + * rte_event_crypto_adapter_create_ext() version.
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @param dev_id
> > + * Event device identifier.
> > + *
> > + * @param port_config
> > + * Argument of type *rte_event_port_conf* that is passed to the
> > +conf_cb
> > + * function.
> > + *
> > + * @param mode
> > + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> > + *
> > + * @return
> > + * - 0: Success
> > + * - <0: Error code on failure
> > + */
> > +int __rte_experimental
> > +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
> > + struct rte_event_port_conf *port_config,
> > + enum rte_event_crypto_adapter_mode mode);
> > +
> [..snip..]
>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Retrieve the event port of an adapter.
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @param [out] event_port_id
> > + * Event port identifier used to link to the queue used in ENQ_DEQ mode.
> > + *
> > + * @return
> > + * - 0: Success
> > + * - <0: Error code on failure.
> > + */
> > +int __rte_experimental
> > +rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t
> > +*event_port_id);
> IIUC, crypto adapter can give packets to multiple event ports.
There could be multiple event ports from cryptodev to eventdev in the HW
which you are referring, by looking at DEQ mode. This API is used only for
ENQ-DEQ mode. The SW adapter is using only one event port to do the job.
>
> Also, I don't see similar API in eth_rx_adapter.
As eth_rx_adapter does not dequeue any events from application,
this API is not present there.
Regards
Abhinandan
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +#endif /* _RTE_EVENT_CRYPTO_ADAPTER_ */
> >
>
> Regards,
> Akhil
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-26 6:07 ` Gujjar, Abhinandan S
@ 2018-04-26 7:16 ` Akhil Goyal
2018-05-03 6:10 ` Gujjar, Abhinandan S
0 siblings, 1 reply; 29+ messages in thread
From: Akhil Goyal @ 2018-04-26 7:16 UTC (permalink / raw)
To: Gujjar, Abhinandan S, Akhil Goyal, jerin.jacob, hemant.agrawal, dev
Cc: Vangati, Narender, Rao, Nikhil, Eads, Gage
Hi Abhinandan,
On 4/26/2018 11:37 AM, Gujjar, Abhinandan S wrote:
> Hi Akhil,
>
>> -----Original Message-----
>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
>> Sent: Wednesday, April 25, 2018 6:12 PM
>> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
>> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com;
>> akhil.goyal@nxp.com; dev@dpdk.org
>> Cc: Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
>> <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>
>> Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
>>
>> Hi Abhinandan,
>> On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
>>> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
>>> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
>>> Signed-off-by: Gage Eads <gage.eads@intel.com>
>>> ---
>>> lib/librte_eventdev/rte_event_crypto_adapter.h | 532
>>> +++++++++++++++++++++++++
>>> 1 file changed, 532 insertions(+)
>>> create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
>>>
>>> diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h
>>> b/lib/librte_eventdev/rte_event_crypto_adapter.h
>>> new file mode 100644
>>> index 0000000..aa4f32c
>>> --- /dev/null
>>> +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
>>> @@ -0,0 +1,532 @@
>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>> + * Copyright(c) 2017-2018 Intel Corporation */
>>> +
>>> +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
>>> +#define _RTE_EVENT_CRYPTO_ADAPTER_
>>> +
>>> +/**
>>> + * @file
>>> + *
>>> + * RTE Event crypto adapter
>>> + *
>>> + * Eventdev library provides couple of adapters to bridge between
>>> +various
>>> + * components for providing new event source. The event crypto
>>> +adapter is
>>> + * one of those adapter which is intended to bridge between event
>>> +devices
>>> + * and crypto devices.
>>> + *
>>> + * The crypto adapter adds support to enqueue/dequeue crypto
>>> +operations to/
>>> + * from event device. The packet flow between crypto device and the
>>> +event
>>> + * device can be accomplished using both SW and HW based transfer
>> mechanisms.
>>> + * The adapter uses an EAL service core function for SW based packet
>>> +transfer
>>> + * and uses the eventdev PMD functions to configure HW based packet
>>> +transfer
>>> + * between the crypto device and the event device.
>>> + *
>>> + * The application can choose to submit a crypto operation directly
>>> +to
>>> + * crypto device or send it to the crypto adapter via eventdev, the
>>> +crypto
>>> + * adapter then submits the crypto operation to the crypto device.
>>> + * The first mode is known as the dequeue only (DEQ_ONLY) mode and
>>> +the
>>> + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode
>>> +can
>>> + * be specified while creating the adapter.
>>> + *
>>> + *
>>> + * Working model of DEQ_ONLY mode:
>>> + * ===============================
>>> + *
>>> + * +--------------+ +--------------+
>>> + * Events | | | Crypto stage |
>>> + * <------>| Event device |-------->| + enqueue to |
>>> + * | | | cryptodev |
>>> + * +--------------+ +--------------+
>>> + * event ^ |
>>> + * enqueue| | crypto
>>> + * | v enqueue
>>> + * +--------------+ +--------------+
>>> + * | | | |
>>> + * |Crypto adapter|<--------| Cryptodev |
>>> + * | | | |
>>> + * +--------------+ +--------------+
>>> + *
>> The diagram looks a bit cryptic. Enqueue to cryptodev will be done from
>> application and not from event device. The arrow from event device to crypto
>> stage is not clear. And application dequeues events from event device. So that
>> should not be bidirectional arrow.
>
> You are right, it is done from application. But the application will be in the crypto stage of
> pipeline. Since crypto is an intermediate stage, events are first dequeued from eventdev to
> find out it's a crypto stage. Then application, in the crypto stage, enqueue "rte_crypto_ops"
> to cryptodev and finally adapter enqueue crypto completions as events to eventdev.
> From this point, eventdev will pass events to the next stage (may be Tx).
> That's the reason behind bidirectional arrow to event device.
>
You are talking about a particular application, but the comments should
be generic. In DEQ ONLY mode, enqueue to cryptodev is responsibility of
application and should not be from event dev. Actually the application
will dequeue from event dev and decide that this event comes from NIC
(say), and it needs to be processed by cryptodev next. So in this case
the application decides what will happen to the packet and not the event
dev, so it cannot be bi-directional arrow.
>>
>>> + * In the DEQ_ONLY mode, application submits crypto operations
>>> + directly to
>>> + * crypto device. The adapter then dequeues crypto completions from
>>> + crypto
>>> + * device and enqueue events to the event device.
>>> + * In this mode, application needs to specify event information
>>> + (response
>>> + * information) which is needed to enqueue an event after the crypto
>>> + operation
>>> + * is completed.
>>> + *
>>> + *
>>> + * Working model of ENQ_DEQ mode:
>>> + * ==============================
>>> + *
>>> + * +--------------+ +--------------+
>>> + * Events | | | |
>>> + * <------>| Event device |-------->| Crypto stage |
>>> + * | | | |
>>> + * +--------------+ +--------------+
>>> + * event ^ |
>>> + * enqueue| | event
>>> + * | v dequeue
>>> + * +---------------------------------------+
>>> + * | |
>>> + * | Crypto adapter |
>>> + * | |
>>> + * +---------------------------------------+
>>> + * ^
>>> + * | crypto
>>> + * | enq/deq
>>> + * v
>>> + * +-------------+
>>> + * | |
>>> + * | Cryptodev |
>>> + * | |
>>> + * +-------------+
>>> + *
>>> + * In the ENQ_DEQ mode, application sends crypto operations as events
>>> + to
>>> + * the adapter which dequeues events and perform cryptodev operations.
>>> + * The adapter dequeues crypto completions from cryptodev and enqueue
>>> + * events to the event device.
>>> + * In this mode, the application needs to specify the cryptodev ID
>>> + * and queue pair ID (request information) needed to enqueue a crypto
>>> + * operation in addition to the event information (response
>>> + information)
>>> + * needed to enqueue an event after the crypto operation has completed.
>>> + *
>>> + *
>>> + * The event crypto adapter provides common APIs to configure the
>>> + packet flow
>>> + * from the crypto device to event devices for both SW and HW based
>> transfers.
>>> + * The crypto event adapter's functions are:
>>> + * - rte_event_crypto_adapter_create_ext()
>>> + * - rte_event_crypto_adapter_create()
>>> + * - rte_event_crypto_adapter_free()
>>> + * - rte_event_crypto_adapter_queue_pair_add()
>>> + * - rte_event_crypto_adapter_queue_pair_del()
>>> + * - rte_event_crypto_adapter_start()
>>> + * - rte_event_crypto_adapter_stop()
>>> + * - rte_event_crypto_adapter_stats_get()
>>> + * - rte_event_crypto_adapter_stats_reset()
>>> +
>>> + * The applicaton creates an instance using
>>> + rte_event_crypto_adapter_create()
>> application spell check.
>>
>>> + * or rte_event_crypto_adapter_create_ext().
>>> + *
>>> + * Cryptodev queue pair addition/deletion is done using the
>>> + * rte_event_crypto_adapter_queue_pair_xxx() APIs.
>>> + *
>>> + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide
>>> + whether
>>> + * request/response(private) data is located in the crypto/security
>>> + session
>>> + * or at an offset in the rte_crypto_op.
>>> + * The rte_crypto_op::private_data_offset provides an offset to
>>> + locate the
>>> + * request/response information in the rte_crypto_op.
>> Above line is repeated below. This one can be removed.
> Ok. I will combine them.
>>
>>> + *
>>> + * For session-based operations, the set and get API provides a
>>> + mechanism for
>>> + * an application to store and retrieve the data information stored
>>> + * along with the crypto session.
>>> +
>>> + * For session-less mode, the adapter gets the private data
>>> + information placed
>>> + * along with the ``struct rte_crypto_op``.
>>> + * The ``rte_crypto_op::private_data_offset`` indicates the start of
>>> + private
>>> + * data information. The offset is counted from the start of the
>>> + rte_crypto_op
>>> + * including initialization vector (IV).
>>> + */
>>> +
>>> +#ifdef __cplusplus
>>> +extern "C" {
>>> +#endif
>>> +
>>> +#include <stdint.h>
>>> +
>>> +#include "rte_eventdev.h"
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this enum may change without prior notice
>>> + *
>>> + * Crypto event adapter mode
>>> + */
>>> +enum rte_event_crypto_adapter_mode {
>>> + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
>>> + /**< Start only dequeue part of crypto adapter.
>>> + * Application submits crypto requests to the cryptodev.
>>> + * Adapter only dequeues the crypto completions from cryptodev
>>> + * and enqueue events to the eventdev.
>>> + */
>>> + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
>>> + /**< Start both enqueue & dequeue part of crypto adapter.
>>> + * Application submits crypto requests as events to the crypto
>>> + * adapter. Adapter submits crypto requests to the cryptodev
>>> + * and crypto completions are enqueued back to the eventdev.
>>> + */
>>> +};
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * Crypto event request structure will be filled by application to
>>> + * provide event request information to the adapter.
>>> + */
>>> +struct rte_event_crypto_request {
>>> + uint8_t resv[8];
>>> + /**< Overlaps with first 8 bytes of struct rte_event
>>> + * that encode the response event information
>>> + */
>> I think in case of ENQ_DEQ mode, both request and response info is required. I
>> think it would be better to have a single structure as
>>
>> struct rte_event_crypto_metadata {
>> struct rte_event ev;
>> uint16_t cdev_id;
>> uint16_t queue_pair_id;
>> uint32_t resv1;
>> };
>> The last 3 fields need not be filled by application for DEQ_ONLY mode.
>> Application will not get confused with request/response structures when we
>> have response info already present in request structure.
>> Or if you still insist to have separate structure for request and response then it
>> would be better to have it as struct instead of union for metadata and remove
>> the resv[8].
>> IMO, first one is better.
>
> rte_event structure itself has enough memory to hold *both request and response information*.
> struct rte_event {
> /** WORD0 */
> union {
> uint64_t event;
> .
> }
> /** WORD1 */
> union {
> uint64_t u64;
> .
> }
> }
>
> For response only *WORD0* is used. Whereas *WORD1* is used for request!
>
> As proposed,
> +struct rte_event_crypto_request {
> + uint8_t resv[8];
> + /**< Overlaps with first 8 bytes of struct rte_event
> + * that encode the response event information
> + */
> + uint16_t cdev_id;
> + /**< cryptodev ID to be used */
> + uint16_t queue_pair_id;
> + /**< cryptodev queue pair ID to be used */
> + uint32_t resv1;
> + /**< Reserved bits */
> +};
>
> First 8 bytes are *WORD0* and rest of the information fits into *WORD1*.
> +union rte_event_crypto_metadata {
> + struct rte_event_crypto_request request_info;
> + struct rte_event response_info;
> +};
> Request and response together into a union will allocate memory required for (WORD0+WORD1).
> I hope, this clarifies all your doubt.
>
Ok I missed the WORD1 in my previous comment. But my intention was to
have a common structure of metadata. As in case of ENQ-DEQ mode, both
request and response will be filled. So having a structure with a union
of request and response will be misleading.
>>
>>> + uint16_t cdev_id;
>>> + /**< cryptodev ID to be used */
>>> + uint16_t queue_pair_id;
>>> + /**< cryptodev queue pair ID to be used */
>>> + uint32_t resv1;
>>> + /**< Reserved bits */
>>> +};
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * Crypto event metadata structure will be filled by application
>>> + * to provide crypto request and event response information.
>>> + *
>>> + * If crypto events are enqueued using a HW mechanism, the cryptodev
>>> + * PMD will use the event response information to set up the event
>>> + * that is enqueued back to eventdev after completion of the crypto
>>> + * operation. If the transfer is done by SW, event response
>>> +information
>>> + * will be used by the adapter.
>>> + */
>>> +union rte_event_crypto_metadata {
>>> + struct rte_event_crypto_request request_info;
>>> + struct rte_event response_info;
>>> +};
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * Adapter configuration structure that the adapter configuration
>>> +callback
>>> + * function is expected to fill out
>>> + * @see rte_event_crypto_adapter_conf_cb */ struct
>>> +rte_event_crypto_adapter_conf {
>>> + uint8_t event_port_id;
>>> + /**< Event port identifier, the adapter enqueues events to this
>>> + * port and also dequeues crypto request events in ENQ_DEQ mode.
>>> + */
>>> + uint32_t max_nb;
>>> + /**< The adapter can return early if it has processed at least
>>> + * max_nb crypto ops. This isn't treated as a requirement; batching
>>> + * may cause the adapter to process more than max_nb crypto ops.
>>> + */
>>> +};
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice
>>> + *
>>> + * Function type used for adapter configuration callback. The
>>> +callback is
>>> + * used to fill in members of the struct
>>> +rte_event_crypto_adapter_conf, this
>>> + * callback is invoked when creating a SW service for packet transfer
>>> +from
>>> + * cryptodev queue pair to the event device. The SW service is
>>> +created within
>>> + * the rte_event_crypto_adapter_queue_pair_add() function if SW based
>>> +packet
>>> + * transfers from cryptodev queue pair to the event device are required.
>>> + *
>>> + * @param id
>>> + * Adapter identifier.
>>> + *
>>> + * @param dev_id
>>> + * Event device identifier.
>>> + *
>>> + * @param conf
>>> + * Structure that needs to be populated by this callback.
>>> + *
>>> + * @param arg
>>> + * Argument to the callback. This is the same as the conf_arg passed
>>> +to the
>>> + * rte_event_crypto_adapter_create_ext().
>>> + */
>>> +typedef int (*rte_event_crypto_adapter_conf_cb) (uint8_t id, uint8_t dev_id,
>>> + struct rte_event_crypto_adapter_conf *conf,
>>> + void *arg);
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * Queue pair configuration structure containing event information.
>>> + * @see
>> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
>>> + */
>>> +struct rte_event_crypto_queue_pair_conf {
>>> + struct rte_event ev;
>>> +};
>> We may not need this wrapper structure. We can directly use rte_event.
> This was done keep in mind to accommodate need for any future requirement
> of having a new field added to the structure along with the rte_event.
>
Do you see anything in the future for configuration. If not, we can
remove it for now and should add in future when it is required.
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * A structure used to retrieve statistics for an event crypto
>>> +adapter
>>> + * instance.
>>> + */
>>> +
>>> +struct rte_event_crypto_adapter_stats {
>>> + uint64_t event_poll_count;
>>> + /**< Event port poll count */
>>> + uint64_t event_dequeue_count;
>> better to use uniform naming. event_deq_count
> ok
>>> + /**< Event dequeue count */
>>> + uint64_t crypto_enq_count;
>>> + /**< Cryptodev enqueue count */
>>> + uint64_t crypto_enq_fail;
>>> + /**< Cryptodev enqueue failed count */
>>> + uint64_t crypto_deq_count;
>>> + /**< Cryptodev dequeue count */
>>> + uint64_t event_enqueue_count;
>> event_enq_count
> ok
>>> + /**< Event enqueue count */
>>> + uint64_t event_enq_retry_count;
>>> + /**< Event enqueue retry count */
>>> + uint64_t event_enq_fail_count;
>>> + /**< Event enqueue fail count */
>>> +};
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice
>>> + *
>>> + * Create a new event crypto adapter with the specified identifier.
>>> + *
>>> + * @param id
>>> + * Adapter identifier.
>>> + *
>>> + * @param dev_id
>>> + * Event device identifier.
>>> + *
>>> + * @param conf_cb
>>> + * Callback function that fills in members of a
>>> + * struct rte_event_crypto_adapter_conf struct passed into
>>> + * it.
>>> + *
>>> + * @param mode
>>> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
>>> + *
>>> + * @param conf_arg
>>> + * Argument that is passed to the conf_cb function.
>>> + *
>>> + * @return
>>> + * - 0: Success
>>> + * - <0: Error code on failure
>>> + */
>>> +int __rte_experimental
>>> +rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id,
>>> + rte_event_crypto_adapter_conf_cb conf_cb,
>>> + enum rte_event_crypto_adapter_mode mode,
>>> + void *conf_arg);
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice
>>> + *
>>> + * Create a new event crypto adapter with the specified identifier.
>>> + * This function uses an internal configuration function that creates
>>> +an event
>>> + * port. This default function reconfigures the event device with an
>>> + * additional event port and setups up the event port using the
>>> +port_config
>> set up
>>> + * parameter passed into this function. In case the application needs
>>> +more
>>> + * control in configuration of the service, it should use the
>>> + * rte_event_crypto_adapter_create_ext() version.
>>> + *
>>> + * @param id
>>> + * Adapter identifier.
>>> + *
>>> + * @param dev_id
>>> + * Event device identifier.
>>> + *
>>> + * @param port_config
>>> + * Argument of type *rte_event_port_conf* that is passed to the
>>> +conf_cb
>>> + * function.
>>> + *
>>> + * @param mode
>>> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
>>> + *
>>> + * @return
>>> + * - 0: Success
>>> + * - <0: Error code on failure
>>> + */
>>> +int __rte_experimental
>>> +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
>>> + struct rte_event_port_conf *port_config,
>>> + enum rte_event_crypto_adapter_mode mode);
>>> +
>> [..snip..]
>>
>>> +
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this API may change without prior notice
>>> + *
>>> + * Retrieve the event port of an adapter.
>>> + *
>>> + * @param id
>>> + * Adapter identifier.
>>> + *
>>> + * @param [out] event_port_id
>>> + * Event port identifier used to link to the queue used in ENQ_DEQ mode.
>>> + *
>>> + * @return
>>> + * - 0: Success
>>> + * - <0: Error code on failure.
>>> + */
>>> +int __rte_experimental
>>> +rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t
>>> +*event_port_id);
>> IIUC, crypto adapter can give packets to multiple event ports.
> There could be multiple event ports from cryptodev to eventdev in the HW
> which you are referring, by looking at DEQ mode. This API is used only for
> ENQ-DEQ mode. The SW adapter is using only one event port to do the job.
A comment shall be added in the description if that is the case.
>>
>> Also, I don't see similar API in eth_rx_adapter.
> As eth_rx_adapter does not dequeue any events from application,
> this API is not present there.
Regards,
Akhil
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-26 7:16 ` Akhil Goyal
@ 2018-05-03 6:10 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-05-03 6:10 UTC (permalink / raw)
To: Akhil Goyal, jerin.jacob, hemant.agrawal, dev
Cc: Vangati, Narender, Rao, Nikhil, Eads, Gage
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Thursday, April 26, 2018 12:47 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Akhil Goyal
> <akhil.goyal@nxp.com>; jerin.jacob@caviumnetworks.com;
> hemant.agrawal@nxp.com; dev@dpdk.org
> Cc: Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>
> Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
>
> Hi Abhinandan,
> On 4/26/2018 11:37 AM, Gujjar, Abhinandan S wrote:
> > Hi Akhil,
> >
> >> -----Original Message-----
> >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> >> Sent: Wednesday, April 25, 2018 6:12 PM
> >> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
> >> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com;
> >> akhil.goyal@nxp.com; dev@dpdk.org
> >> Cc: Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
> >> <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>
> >> Subject: Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto
> >> adapter
> >>
> >> Hi Abhinandan,
> >> On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> >>> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> >>> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> >>> Signed-off-by: Gage Eads <gage.eads@intel.com>
> >>> ---
> >>> lib/librte_eventdev/rte_event_crypto_adapter.h | 532
> >>> +++++++++++++++++++++++++
> >>> 1 file changed, 532 insertions(+)
> >>> create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
> >>>
> >>> diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h
> >>> b/lib/librte_eventdev/rte_event_crypto_adapter.h
> >>> new file mode 100644
> >>> index 0000000..aa4f32c
> >>> --- /dev/null
> >>> +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> >>> @@ -0,0 +1,532 @@
> >>> +/* SPDX-License-Identifier: BSD-3-Clause
> >>> + * Copyright(c) 2017-2018 Intel Corporation */
> >>> +
> >>> +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> >>> +#define _RTE_EVENT_CRYPTO_ADAPTER_
> >>> +
> >>> +/**
> >>> + * @file
> >>> + *
> >>> + * RTE Event crypto adapter
> >>> + *
> >>> + * Eventdev library provides couple of adapters to bridge between
> >>> +various
> >>> + * components for providing new event source. The event crypto
> >>> +adapter is
> >>> + * one of those adapter which is intended to bridge between event
> >>> +devices
> >>> + * and crypto devices.
> >>> + *
> >>> + * The crypto adapter adds support to enqueue/dequeue crypto
> >>> +operations to/
> >>> + * from event device. The packet flow between crypto device and the
> >>> +event
> >>> + * device can be accomplished using both SW and HW based transfer
> >> mechanisms.
> >>> + * The adapter uses an EAL service core function for SW based
> >>> +packet transfer
> >>> + * and uses the eventdev PMD functions to configure HW based packet
> >>> +transfer
> >>> + * between the crypto device and the event device.
> >>> + *
> >>> + * The application can choose to submit a crypto operation directly
> >>> +to
> >>> + * crypto device or send it to the crypto adapter via eventdev, the
> >>> +crypto
> >>> + * adapter then submits the crypto operation to the crypto device.
> >>> + * The first mode is known as the dequeue only (DEQ_ONLY) mode and
> >>> +the
> >>> + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of
> >>> +mode can
> >>> + * be specified while creating the adapter.
> >>> + *
> >>> + *
> >>> + * Working model of DEQ_ONLY mode:
> >>> + * ===============================
> >>> + *
> >>> + * +--------------+ +--------------+
> >>> + * Events | | | Crypto stage |
> >>> + * <------>| Event device |-------->| + enqueue to |
> >>> + * | | | cryptodev |
> >>> + * +--------------+ +--------------+
> >>> + * event ^ |
> >>> + * enqueue| | crypto
> >>> + * | v enqueue
> >>> + * +--------------+ +--------------+
> >>> + * | | | |
> >>> + * |Crypto adapter|<--------| Cryptodev |
> >>> + * | | | |
> >>> + * +--------------+ +--------------+
> >>> + *
> >> The diagram looks a bit cryptic. Enqueue to cryptodev will be done
> >> from application and not from event device. The arrow from event
> >> device to crypto stage is not clear. And application dequeues events
> >> from event device. So that should not be bidirectional arrow.
> >
> > You are right, it is done from application. But the application will
> > be in the crypto stage of pipeline. Since crypto is an intermediate
> > stage, events are first dequeued from eventdev to find out it's a crypto stage.
> Then application, in the crypto stage, enqueue "rte_crypto_ops"
> > to cryptodev and finally adapter enqueue crypto completions as events to
> eventdev.
> > From this point, eventdev will pass events to the next stage (may be Tx).
> > That's the reason behind bidirectional arrow to event device.
> >
> You are talking about a particular application, but the comments should be
> generic. In DEQ ONLY mode, enqueue to cryptodev is responsibility of
> application and should not be from event dev. Actually the application will
> dequeue from event dev and decide that this event comes from NIC (say), and it
> needs to be processed by cryptodev next. So in this case the application decides
> what will happen to the packet and not the event dev, so it cannot be bi-
> directional arrow.
I will update the diagram with sequence numbers providing more information
on what's happening at each block. This will give more clarity.
BTW, the arrow from eventdev to crypto is unidirectional.
>
> >>
> >>> + * In the DEQ_ONLY mode, application submits crypto operations
> >>> + directly to
> >>> + * crypto device. The adapter then dequeues crypto completions from
> >>> + crypto
> >>> + * device and enqueue events to the event device.
> >>> + * In this mode, application needs to specify event information
> >>> + (response
> >>> + * information) which is needed to enqueue an event after the
> >>> + crypto operation
> >>> + * is completed.
> >>> + *
> >>> + *
> >>> + * Working model of ENQ_DEQ mode:
> >>> + * ==============================
> >>> + *
> >>> + * +--------------+ +--------------+
> >>> + * Events | | | |
> >>> + * <------>| Event device |-------->| Crypto stage |
> >>> + * | | | |
> >>> + * +--------------+ +--------------+
> >>> + * event ^ |
> >>> + * enqueue| | event
> >>> + * | v dequeue
> >>> + * +---------------------------------------+
> >>> + * | |
> >>> + * | Crypto adapter |
> >>> + * | |
> >>> + * +---------------------------------------+
> >>> + * ^
> >>> + * | crypto
> >>> + * | enq/deq
> >>> + * v
> >>> + * +-------------+
> >>> + * | |
> >>> + * | Cryptodev |
> >>> + * | |
> >>> + * +-------------+
> >>> + *
> >>> + * In the ENQ_DEQ mode, application sends crypto operations as
> >>> + events to
> >>> + * the adapter which dequeues events and perform cryptodev operations.
> >>> + * The adapter dequeues crypto completions from cryptodev and
> >>> + enqueue
> >>> + * events to the event device.
> >>> + * In this mode, the application needs to specify the cryptodev ID
> >>> + * and queue pair ID (request information) needed to enqueue a
> >>> + crypto
> >>> + * operation in addition to the event information (response
> >>> + information)
> >>> + * needed to enqueue an event after the crypto operation has completed.
> >>> + *
> >>> + *
> >>> + * The event crypto adapter provides common APIs to configure the
> >>> + packet flow
> >>> + * from the crypto device to event devices for both SW and HW based
> >> transfers.
> >>> + * The crypto event adapter's functions are:
> >>> + * - rte_event_crypto_adapter_create_ext()
> >>> + * - rte_event_crypto_adapter_create()
> >>> + * - rte_event_crypto_adapter_free()
> >>> + * - rte_event_crypto_adapter_queue_pair_add()
> >>> + * - rte_event_crypto_adapter_queue_pair_del()
> >>> + * - rte_event_crypto_adapter_start()
> >>> + * - rte_event_crypto_adapter_stop()
> >>> + * - rte_event_crypto_adapter_stats_get()
> >>> + * - rte_event_crypto_adapter_stats_reset()
> >>> +
> >>> + * The applicaton creates an instance using
> >>> + rte_event_crypto_adapter_create()
> >> application spell check.
> >>
> >>> + * or rte_event_crypto_adapter_create_ext().
> >>> + *
> >>> + * Cryptodev queue pair addition/deletion is done using the
> >>> + * rte_event_crypto_adapter_queue_pair_xxx() APIs.
> >>> + *
> >>> + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide
> >>> + whether
> >>> + * request/response(private) data is located in the crypto/security
> >>> + session
> >>> + * or at an offset in the rte_crypto_op.
> >>> + * The rte_crypto_op::private_data_offset provides an offset to
> >>> + locate the
> >>> + * request/response information in the rte_crypto_op.
> >> Above line is repeated below. This one can be removed.
> > Ok. I will combine them.
> >>
> >>> + *
> >>> + * For session-based operations, the set and get API provides a
> >>> + mechanism for
> >>> + * an application to store and retrieve the data information stored
> >>> + * along with the crypto session.
> >>> +
> >>> + * For session-less mode, the adapter gets the private data
> >>> + information placed
> >>> + * along with the ``struct rte_crypto_op``.
> >>> + * The ``rte_crypto_op::private_data_offset`` indicates the start
> >>> + of private
> >>> + * data information. The offset is counted from the start of the
> >>> + rte_crypto_op
> >>> + * including initialization vector (IV).
> >>> + */
> >>> +
> >>> +#ifdef __cplusplus
> >>> +extern "C" {
> >>> +#endif
> >>> +
> >>> +#include <stdint.h>
> >>> +
> >>> +#include "rte_eventdev.h"
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this enum may change without prior notice
> >>> + *
> >>> + * Crypto event adapter mode
> >>> + */
> >>> +enum rte_event_crypto_adapter_mode {
> >>> + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
> >>> + /**< Start only dequeue part of crypto adapter.
> >>> + * Application submits crypto requests to the cryptodev.
> >>> + * Adapter only dequeues the crypto completions from cryptodev
> >>> + * and enqueue events to the eventdev.
> >>> + */
> >>> + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
> >>> + /**< Start both enqueue & dequeue part of crypto adapter.
> >>> + * Application submits crypto requests as events to the crypto
> >>> + * adapter. Adapter submits crypto requests to the cryptodev
> >>> + * and crypto completions are enqueued back to the eventdev.
> >>> + */
> >>> +};
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >>> + *
> >>> + * Crypto event request structure will be filled by application to
> >>> + * provide event request information to the adapter.
> >>> + */
> >>> +struct rte_event_crypto_request {
> >>> + uint8_t resv[8];
> >>> + /**< Overlaps with first 8 bytes of struct rte_event
> >>> + * that encode the response event information
> >>> + */
> >> I think in case of ENQ_DEQ mode, both request and response info is
> >> required. I think it would be better to have a single structure as
> >>
> >> struct rte_event_crypto_metadata {
> >> struct rte_event ev;
> >> uint16_t cdev_id;
> >> uint16_t queue_pair_id;
> >> uint32_t resv1;
> >> };
> >> The last 3 fields need not be filled by application for DEQ_ONLY mode.
> >> Application will not get confused with request/response structures
> >> when we have response info already present in request structure.
> >> Or if you still insist to have separate structure for request and
> >> response then it would be better to have it as struct instead of
> >> union for metadata and remove the resv[8].
> >> IMO, first one is better.
> >
> > rte_event structure itself has enough memory to hold *both request and
> response information*.
> > struct rte_event {
> > /** WORD0 */
> > union {
> > uint64_t event;
> > .
> > }
> > /** WORD1 */
> > union {
> > uint64_t u64;
> > .
> > }
> > }
> >
> > For response only *WORD0* is used. Whereas *WORD1* is used for request!
> >
> > As proposed,
> > +struct rte_event_crypto_request {
> > + uint8_t resv[8];
> > + /**< Overlaps with first 8 bytes of struct rte_event
> > + * that encode the response event information
> > + */
> > + uint16_t cdev_id;
> > + /**< cryptodev ID to be used */
> > + uint16_t queue_pair_id;
> > + /**< cryptodev queue pair ID to be used */
> > + uint32_t resv1;
> > + /**< Reserved bits */
> > +};
> >
> > First 8 bytes are *WORD0* and rest of the information fits into *WORD1*.
> > +union rte_event_crypto_metadata {
> > + struct rte_event_crypto_request request_info;
> > + struct rte_event response_info;
> > +};
> > Request and response together into a union will allocate memory required for
> (WORD0+WORD1).
> > I hope, this clarifies all your doubt.
> >
> Ok I missed the WORD1 in my previous comment. But my intention was to have
> a common structure of metadata. As in case of ENQ-DEQ mode, both request
> and response will be filled. So having a structure with a union of request and
> response will be misleading.
>
> >>
> >>> + uint16_t cdev_id;
> >>> + /**< cryptodev ID to be used */
> >>> + uint16_t queue_pair_id;
> >>> + /**< cryptodev queue pair ID to be used */
> >>> + uint32_t resv1;
> >>> + /**< Reserved bits */
> >>> +};
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >>> + *
> >>> + * Crypto event metadata structure will be filled by application
> >>> + * to provide crypto request and event response information.
> >>> + *
> >>> + * If crypto events are enqueued using a HW mechanism, the cryptodev
> >>> + * PMD will use the event response information to set up the event
> >>> + * that is enqueued back to eventdev after completion of the crypto
> >>> + * operation. If the transfer is done by SW, event response
> >>> +information
> >>> + * will be used by the adapter.
> >>> + */
> >>> +union rte_event_crypto_metadata {
> >>> + struct rte_event_crypto_request request_info;
> >>> + struct rte_event response_info;
> >>> +};
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >>> + *
> >>> + * Adapter configuration structure that the adapter configuration
> >>> +callback
> >>> + * function is expected to fill out
> >>> + * @see rte_event_crypto_adapter_conf_cb */ struct
> >>> +rte_event_crypto_adapter_conf {
> >>> + uint8_t event_port_id;
> >>> + /**< Event port identifier, the adapter enqueues events to this
> >>> + * port and also dequeues crypto request events in ENQ_DEQ mode.
> >>> + */
> >>> + uint32_t max_nb;
> >>> + /**< The adapter can return early if it has processed at least
> >>> + * max_nb crypto ops. This isn't treated as a requirement; batching
> >>> + * may cause the adapter to process more than max_nb crypto ops.
> >>> + */
> >>> +};
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this API may change without prior notice
> >>> + *
> >>> + * Function type used for adapter configuration callback. The
> >>> +callback is
> >>> + * used to fill in members of the struct
> >>> +rte_event_crypto_adapter_conf, this
> >>> + * callback is invoked when creating a SW service for packet transfer
> >>> +from
> >>> + * cryptodev queue pair to the event device. The SW service is
> >>> +created within
> >>> + * the rte_event_crypto_adapter_queue_pair_add() function if SW based
> >>> +packet
> >>> + * transfers from cryptodev queue pair to the event device are required.
> >>> + *
> >>> + * @param id
> >>> + * Adapter identifier.
> >>> + *
> >>> + * @param dev_id
> >>> + * Event device identifier.
> >>> + *
> >>> + * @param conf
> >>> + * Structure that needs to be populated by this callback.
> >>> + *
> >>> + * @param arg
> >>> + * Argument to the callback. This is the same as the conf_arg passed
> >>> +to the
> >>> + * rte_event_crypto_adapter_create_ext().
> >>> + */
> >>> +typedef int (*rte_event_crypto_adapter_conf_cb) (uint8_t id, uint8_t
> dev_id,
> >>> + struct rte_event_crypto_adapter_conf *conf,
> >>> + void *arg);
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >>> + *
> >>> + * Queue pair configuration structure containing event information.
> >>> + * @see
> >> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
> >>> + */
> >>> +struct rte_event_crypto_queue_pair_conf {
> >>> + struct rte_event ev;
> >>> +};
> >> We may not need this wrapper structure. We can directly use rte_event.
> > This was done keep in mind to accommodate need for any future requirement
> > of having a new field added to the structure along with the rte_event.
> >
> Do you see anything in the future for configuration. If not, we can
> remove it for now and should add in future when it is required.
Sure. I will remove it in next patch.
>
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this structure may change without prior notice
> >>> + *
> >>> + * A structure used to retrieve statistics for an event crypto
> >>> +adapter
> >>> + * instance.
> >>> + */
> >>> +
> >>> +struct rte_event_crypto_adapter_stats {
> >>> + uint64_t event_poll_count;
> >>> + /**< Event port poll count */
> >>> + uint64_t event_dequeue_count;
> >> better to use uniform naming. event_deq_count
> > ok
> >>> + /**< Event dequeue count */
> >>> + uint64_t crypto_enq_count;
> >>> + /**< Cryptodev enqueue count */
> >>> + uint64_t crypto_enq_fail;
> >>> + /**< Cryptodev enqueue failed count */
> >>> + uint64_t crypto_deq_count;
> >>> + /**< Cryptodev dequeue count */
> >>> + uint64_t event_enqueue_count;
> >> event_enq_count
> > ok
> >>> + /**< Event enqueue count */
> >>> + uint64_t event_enq_retry_count;
> >>> + /**< Event enqueue retry count */
> >>> + uint64_t event_enq_fail_count;
> >>> + /**< Event enqueue fail count */
> >>> +};
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this API may change without prior notice
> >>> + *
> >>> + * Create a new event crypto adapter with the specified identifier.
> >>> + *
> >>> + * @param id
> >>> + * Adapter identifier.
> >>> + *
> >>> + * @param dev_id
> >>> + * Event device identifier.
> >>> + *
> >>> + * @param conf_cb
> >>> + * Callback function that fills in members of a
> >>> + * struct rte_event_crypto_adapter_conf struct passed into
> >>> + * it.
> >>> + *
> >>> + * @param mode
> >>> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> >>> + *
> >>> + * @param conf_arg
> >>> + * Argument that is passed to the conf_cb function.
> >>> + *
> >>> + * @return
> >>> + * - 0: Success
> >>> + * - <0: Error code on failure
> >>> + */
> >>> +int __rte_experimental
> >>> +rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id,
> >>> + rte_event_crypto_adapter_conf_cb conf_cb,
> >>> + enum rte_event_crypto_adapter_mode mode,
> >>> + void *conf_arg);
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this API may change without prior notice
> >>> + *
> >>> + * Create a new event crypto adapter with the specified identifier.
> >>> + * This function uses an internal configuration function that creates
> >>> +an event
> >>> + * port. This default function reconfigures the event device with an
> >>> + * additional event port and setups up the event port using the
> >>> +port_config
> >> set up
> >>> + * parameter passed into this function. In case the application needs
> >>> +more
> >>> + * control in configuration of the service, it should use the
> >>> + * rte_event_crypto_adapter_create_ext() version.
> >>> + *
> >>> + * @param id
> >>> + * Adapter identifier.
> >>> + *
> >>> + * @param dev_id
> >>> + * Event device identifier.
> >>> + *
> >>> + * @param port_config
> >>> + * Argument of type *rte_event_port_conf* that is passed to the
> >>> +conf_cb
> >>> + * function.
> >>> + *
> >>> + * @param mode
> >>> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> >>> + *
> >>> + * @return
> >>> + * - 0: Success
> >>> + * - <0: Error code on failure
> >>> + */
> >>> +int __rte_experimental
> >>> +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
> >>> + struct rte_event_port_conf *port_config,
> >>> + enum rte_event_crypto_adapter_mode mode);
> >>> +
> >> [..snip..]
> >>
> >>> +
> >>> +/**
> >>> + * @warning
> >>> + * @b EXPERIMENTAL: this API may change without prior notice
> >>> + *
> >>> + * Retrieve the event port of an adapter.
> >>> + *
> >>> + * @param id
> >>> + * Adapter identifier.
> >>> + *
> >>> + * @param [out] event_port_id
> >>> + * Event port identifier used to link to the queue used in ENQ_DEQ mode.
> >>> + *
> >>> + * @return
> >>> + * - 0: Success
> >>> + * - <0: Error code on failure.
> >>> + */
> >>> +int __rte_experimental
> >>> +rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t
> >>> +*event_port_id);
> >> IIUC, crypto adapter can give packets to multiple event ports.
> > There could be multiple event ports from cryptodev to eventdev in the HW
> > which you are referring, by looking at DEQ mode. This API is used only for
> > ENQ-DEQ mode. The SW adapter is using only one event port to do the job.
> A comment shall be added in the description if that is the case.
I have added a comment just below " param [out] event_port_id". I will try to add
some more information, if possible.
> >>
> >> Also, I don't see similar API in eth_rx_adapter.
> > As eth_rx_adapter does not dequeue any events from application,
> > this API is not present there.
>
> Regards,
> Akhil
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-24 12:43 ` [dpdk-dev] [v2,1/6] eventdev: introduce event " Abhinandan Gujjar
2018-04-25 12:42 ` Akhil Goyal
@ 2018-04-29 16:08 ` Jerin Jacob
2018-05-03 6:03 ` Gujjar, Abhinandan S
1 sibling, 1 reply; 29+ messages in thread
From: Jerin Jacob @ 2018-04-29 16:08 UTC (permalink / raw)
To: Abhinandan Gujjar
Cc: hemant.agrawal, akhil.goyal, dev, narender.vangati, nikhil.rao,
gage.eads
-----Original Message-----
> Date: Tue, 24 Apr 2018 18:13:22 +0530
> From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> akhil.goyal@nxp.com, dev@dpdk.org
> CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> nikhil.rao@intel.com, gage.eads@intel.com
> Subject: [v2,1/6] eventdev: introduce event crypto adapter
> X-Mailer: git-send-email 1.9.1
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> lib/librte_eventdev/rte_event_crypto_adapter.h | 532 +++++++++++++++++++++++++
> 1 file changed, 532 insertions(+)
> create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
>
> diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h b/lib/librte_eventdev/rte_event_crypto_adapter.h
> new file mode 100644
> index 0000000..aa4f32c
> --- /dev/null
> +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> @@ -0,0 +1,532 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2017-2018 Intel Corporation
> + */
> +
> +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> +#define _RTE_EVENT_CRYPTO_ADAPTER_
1) Please rebase to next-eventdev tree, If everything goes well, we will
try to add it in RC2.
2) Please update MAINTAINERS section in this patch set with just one
rte_event_crypto_adapter.h file and as when you add new files update the
new files in the MAINTAINERS file
> +
> +/**
> + * @file
> + *
> + * RTE Event crypto adapter
> + *
> + * Eventdev library provides couple of adapters to bridge between various
> + * components for providing new event source. The event crypto adapter is
> + * one of those adapter which is intended to bridge between event devices
> + * and crypto devices.
> + *
> + * The crypto adapter adds support to enqueue/dequeue crypto operations to/
> + * from event device. The packet flow between crypto device and the event
> + * device can be accomplished using both SW and HW based transfer mechanisms.
> + * The adapter uses an EAL service core function for SW based packet transfer
> + * and uses the eventdev PMD functions to configure HW based packet transfer
> + * between the crypto device and the event device.
> + *
> + * The application can choose to submit a crypto operation directly to
> + * crypto device or send it to the crypto adapter via eventdev, the crypto
> + * adapter then submits the crypto operation to the crypto device.
> + * The first mode is known as the dequeue only (DEQ_ONLY) mode and the
> + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode can
> + * be specified while creating the adapter.
We need to tell why these modes are required or use of it/when to use
what like, OPS_NEW does not maintain ingress order. example, use of DEQ_ONLY with
FWD or ENQ_DEQ mode to use ingress order maintenance.
> + *
> + *
> + * Working model of DEQ_ONLY mode:
> + * ===============================
This diagram is not rendering correctly in doxygen html file.
check lib/librte_eventdev/rte_eventdev.h as reference.
invoke "make doc-api-html" to see the html output.
> + *
> + * +--------------+ +--------------+
> + * Events | | | Crypto stage |
> + * <------>| Event device |-------->| + enqueue to |
> + * | | | cryptodev |
> + * +--------------+ +--------------+
> + * event ^ |
> + * enqueue| | crypto
> + * | v enqueue
> + * +--------------+ +--------------+
> + * | | | |
> + * |Crypto adapter|<--------| Cryptodev |
> + * | | | |
> + * +--------------+ +--------------+
> + *
I think, we need to add sequence of numbers scheme to define the
data flow for this diagram as it is complex.
something like, ------[1]----> and describe the action means.
> + * In the DEQ_ONLY mode, application submits crypto operations directly to
> + * crypto device. The adapter then dequeues crypto completions from crypto
> + * device and enqueue events to the event device.
> + * In this mode, application needs to specify event information (response
> + * information) which is needed to enqueue an event after the crypto operation
> + * is completed.
> + *
> + *
> + * Working model of ENQ_DEQ mode:
> + * ==============================
> + *
> + * +--------------+ +--------------+
> + * Events | | | |
> + * <------>| Event device |-------->| Crypto stage |
> + * | | | |
> + * +--------------+ +--------------+
I think, instead of "crypto stage", it is better to call it as "atomic stage" something
like that where the source queue's(ORDERED mode) ingress order will be updated
in that stage and then enqueue to cryptodev happens for ingress order maintenance.
> + * event ^ |
> + * enqueue| | event
> + * | v dequeue
> + * +---------------------------------------+
> + * | |
> + * | Crypto adapter |
> + * | |
> + * +---------------------------------------+
> + * ^
> + * | crypto
> + * | enq/deq
> + * v
> + * +-------------+
> + * | |
> + * | Cryptodev |
> + * | |
> + * +-------------+
Same as above comments for the diagram(i.e adding sequence number)
> + *
> + * In the ENQ_DEQ mode, application sends crypto operations as events to
> + * the adapter which dequeues events and perform cryptodev operations.
^^^^^^^
Not to the adapter, right?. applications sends to the eventdev through
ports available through rte_event_crypto_adapter_event_port_get() eventdev port. Right?
Please reword if it makes sense.
> + * The adapter dequeues crypto completions from cryptodev and enqueue
> + * events to the event device.
> + * In this mode, the application needs to specify the cryptodev ID
> + * and queue pair ID (request information) needed to enqueue a crypto
> + * operation in addition to the event information (response information)
> + * needed to enqueue an event after the crypto operation has completed.
> + *
> + *
> + * The event crypto adapter provides common APIs to configure the packet flow
> + * from the crypto device to event devices for both SW and HW based transfers.
> + * The crypto event adapter's functions are:
> + * - rte_event_crypto_adapter_create_ext()
> + * - rte_event_crypto_adapter_create()
> + * - rte_event_crypto_adapter_free()
> + * - rte_event_crypto_adapter_queue_pair_add()
> + * - rte_event_crypto_adapter_queue_pair_del()
> + * - rte_event_crypto_adapter_start()
> + * - rte_event_crypto_adapter_stop()
> + * - rte_event_crypto_adapter_stats_get()
> + * - rte_event_crypto_adapter_stats_reset()
> +
> + * The applicaton creates an instance using rte_event_crypto_adapter_create()
s/application/application
> + * or rte_event_crypto_adapter_create_ext().
> + *
> + * Cryptodev queue pair addition/deletion is done using the
> + * rte_event_crypto_adapter_queue_pair_xxx() APIs.
I think, we can mention the connection of
RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND capability here.
> + *
> + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide whether
> + * request/response(private) data is located in the crypto/security session
> + * or at an offset in the rte_crypto_op.
> + * The rte_crypto_op::private_data_offset provides an offset to locate the
> + * request/response information in the rte_crypto_op.
> + *
> + * For session-based operations, the set and get API provides a mechanism for
> + * an application to store and retrieve the data information stored
> + * along with the crypto session.
I think, we can mention the connection of
RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA capability here.
> +
> + * For session-less mode, the adapter gets the private data information placed
> + * along with the ``struct rte_crypto_op``.
> + * The ``rte_crypto_op::private_data_offset`` indicates the start of private
> + * data information. The offset is counted from the start of the rte_crypto_op
> + * including initialization vector (IV).
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <stdint.h>
> +
> +#include "rte_eventdev.h"
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this enum may change without prior notice
> + *
> + * Crypto event adapter mode
> + */
> +enum rte_event_crypto_adapter_mode {
> + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
Why to mark it as explicit '1' ?
> + /**< Start only dequeue part of crypto adapter.
> + * Application submits crypto requests to the cryptodev.
> + * Adapter only dequeues the crypto completions from cryptodev
> + * and enqueue events to the eventdev.
I think, you can mention the connection with below capabilities here.
RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW
RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD
and @see of those here.
> + */
> + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
> + /**< Start both enqueue & dequeue part of crypto adapter.
> + * Application submits crypto requests as events to the crypto
> + * adapter. Adapter submits crypto requests to the cryptodev
> + * and crypto completions are enqueued back to the eventdev.
IMO, You can add note when this mode will be used by application if
device is not capable of RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD
and application need ingress order maintenance or something like that.
> + */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Crypto event request structure will be filled by application to
> + * provide event request information to the adapter.
> + */
> +struct rte_event_crypto_request {
> + uint8_t resv[8];
> + /**< Overlaps with first 8 bytes of struct rte_event
> + * that encode the response event information
May be we could add more comments on application usage on updating
struct rte_event based field updating for response event information.
> + */
> + uint16_t cdev_id;
> + /**< cryptodev ID to be used */
> + uint16_t queue_pair_id;
> + /**< cryptodev queue pair ID to be used */
> + uint32_t resv1;
How about rsvd ? No strong opinion though.
I think, you can add, Valid when it adapter is in ENQ_DEQ mode
> + /**< Reserved bits */
> +};
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Crypto event metadata structure will be filled by application
> + * to provide crypto request and event response information.
> + *
> + * If crypto events are enqueued using a HW mechanism, the cryptodev
> + * PMD will use the event response information to set up the event
> + * that is enqueued back to eventdev after completion of the crypto
> + * operation. If the transfer is done by SW, event response information
> + * will be used by the adapter.
> + */
> +union rte_event_crypto_metadata {
> + struct rte_event_crypto_request request_info;
I think, you can add, Provided by application for ENQ_DEQ mode
> + struct rte_event response_info;
I think, you can add, Provided by application for ENQ_DEQ and DEQ_ONLY
mode.
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * Queue pair configuration structure containing event information.
> + * @see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
> + */
> +struct rte_event_crypto_queue_pair_conf {
> + struct rte_event ev;
MO, As Akhil said, we can pass struct rte_event directly.
> +};
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Create a new event crypto adapter with the specified identifier.
> + * This function uses an internal configuration function that creates an event
> + * port. This default function reconfigures the event device with an
> + * additional event port and setups up the event port using the port_config
> + * parameter passed into this function. In case the application needs more
> + * control in configuration of the service, it should use the
> + * rte_event_crypto_adapter_create_ext() version.
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @param dev_id
> + * Event device identifier.
> + *
> + * @param port_config
> + * Argument of type *rte_event_port_conf* that is passed to the conf_cb
> + * function.
> + *
> + * @param mode
> + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure
> + */
> +int __rte_experimental
> +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
> + struct rte_event_port_conf *port_config,
> + enum rte_event_crypto_adapter_mode mode);
- Detecting what to pass (RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY or
RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ)
in application need a lot checks based on capabilities, instead, How
about passing whats been desired by the application by adding a new
enum(RTE_EVENT_CRYPTO_ADAPTER_MODE_OP_NEW or RTE_EVENT_CRYPTO_ADAPTER_MODE_OP_FWD).
and internally based on mode selected and the device capability, the common
code can choose RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY in NEW or FWD mode vs
RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ.
- We could add common code based API to return the exiting configured mode.
enum rte_event_crypto_adapter_mode mode __rte_experimental
rte_event_crypto_adapter_mode_get(uint8_t id, uint8_t dev_id);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Free an event crypto adapter
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @return
> + * - 0: Success
> + * - <0: Error code on failure, If the adapter still has queue pairs
> + * added to it, the function returns -EBUSY.
> + */
> +int __rte_experimental
> +rte_event_crypto_adapter_free(uint8_t id);
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Add a queue pair to an event crypto adapter.
> + *
> + * @param id
> + * Adapter identifier.
> + *
> + * @param cdev_id
> + * Cryptodev identifier.
> + *
> + * @param queue_pair_id
> + * Cryptodev queue pair identifier. If queue_pair_id is set -1,
> + * adapter adds all the pre configured queue pairs to the instance.
> + *
> + * @param conf
> + * Additional configuration structure of type
> + * *rte_event_crypto_queue_pair_conf*
@see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-04-29 16:08 ` Jerin Jacob
@ 2018-05-03 6:03 ` Gujjar, Abhinandan S
2018-05-03 9:02 ` Jerin Jacob
0 siblings, 1 reply; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-05-03 6:03 UTC (permalink / raw)
To: Jerin Jacob
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
> -----Original Message-----
> From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Sent: Sunday, April 29, 2018 9:39 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> Eads, Gage <gage.eads@intel.com>
> Subject: Re: [v2,1/6] eventdev: introduce event crypto adapter
>
> -----Original Message-----
> > Date: Tue, 24 Apr 2018 18:13:22 +0530
> > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > akhil.goyal@nxp.com, dev@dpdk.org
> > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > nikhil.rao@intel.com, gage.eads@intel.com
> > Subject: [v2,1/6] eventdev: introduce event crypto adapter
> > X-Mailer: git-send-email 1.9.1
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
> > lib/librte_eventdev/rte_event_crypto_adapter.h | 532
> > +++++++++++++++++++++++++
> > 1 file changed, 532 insertions(+)
> > create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
> >
> > diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h
> > b/lib/librte_eventdev/rte_event_crypto_adapter.h
> > new file mode 100644
> > index 0000000..aa4f32c
> > --- /dev/null
> > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> > @@ -0,0 +1,532 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2017-2018 Intel Corporation */
> > +
> > +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> > +#define _RTE_EVENT_CRYPTO_ADAPTER_
>
> 1) Please rebase to next-eventdev tree, If everything goes well, we will try to
> add it in RC2.
Ok
>
> 2) Please update MAINTAINERS section in this patch set with just one
> rte_event_crypto_adapter.h file and as when you add new files update the new
> files in the MAINTAINERS file
Ok
>
> > +
> > +/**
> > + * @file
> > + *
> > + * RTE Event crypto adapter
> > + *
> > + * Eventdev library provides couple of adapters to bridge between
> > +various
> > + * components for providing new event source. The event crypto
> > +adapter is
> > + * one of those adapter which is intended to bridge between event
> > +devices
> > + * and crypto devices.
> > + *
> > + * The crypto adapter adds support to enqueue/dequeue crypto
> > +operations to/
> > + * from event device. The packet flow between crypto device and the
> > +event
> > + * device can be accomplished using both SW and HW based transfer
> mechanisms.
> > + * The adapter uses an EAL service core function for SW based packet
> > +transfer
> > + * and uses the eventdev PMD functions to configure HW based packet
> > +transfer
> > + * between the crypto device and the event device.
> > + *
> > + * The application can choose to submit a crypto operation directly
> > +to
> > + * crypto device or send it to the crypto adapter via eventdev, the
> > +crypto
> > + * adapter then submits the crypto operation to the crypto device.
> > + * The first mode is known as the dequeue only (DEQ_ONLY) mode and
> > +the
> > + * second as the enqueue - dequeue (ENQ_DEQ) mode. The choice of mode
> > +can
> > + * be specified while creating the adapter.
>
> We need to tell why these modes are required or use of it/when to use what
> like, OPS_NEW does not maintain ingress order. example, use of DEQ_ONLY
> with FWD or ENQ_DEQ mode to use ingress order maintenance.
Sure. I will add some more information for clarity.
>
>
> > + *
> > + *
> > + * Working model of DEQ_ONLY mode:
> > + * ===============================
>
> This diagram is not rendering correctly in doxygen html file.
> check lib/librte_eventdev/rte_eventdev.h as reference.
>
> invoke "make doc-api-html" to see the html output.
>
>
> > + *
> > + * +--------------+ +--------------+
> > + * Events | | | Crypto stage |
> > + * <------>| Event device |-------->| + enqueue to |
> > + * | | | cryptodev |
> > + * +--------------+ +--------------+
> > + * event ^ |
> > + * enqueue| | crypto
> > + * | v enqueue
> > + * +--------------+ +--------------+
> > + * | | | |
> > + * |Crypto adapter|<--------| Cryptodev |
> > + * | | | |
> > + * +--------------+ +--------------+
> > + *
>
> I think, we need to add sequence of numbers scheme to define the data flow for
> this diagram as it is complex.
>
> something like, ------[1]----> and describe the action means.
Sure. I will add sequence number to the flow. Akhil also have some concern on this.
With the sequence number, it be will be more clear.
>
> > + * In the DEQ_ONLY mode, application submits crypto operations
> > + directly to
> > + * crypto device. The adapter then dequeues crypto completions from
> > + crypto
> > + * device and enqueue events to the event device.
> > + * In this mode, application needs to specify event information
> > + (response
> > + * information) which is needed to enqueue an event after the crypto
> > + operation
> > + * is completed.
> > + *
> > + *
> > + * Working model of ENQ_DEQ mode:
> > + * ==============================
> > + *
> > + * +--------------+ +--------------+
> > + * Events | | | |
> > + * <------>| Event device |-------->| Crypto stage |
> > + * | | | |
> > + * +--------------+ +--------------+
>
> I think, instead of "crypto stage", it is better to call it as "atomic stage"
> something like that where the source queue's(ORDERED mode) ingress order will
> be updated in that stage and then enqueue to cryptodev happens for ingress
> order maintenance.
Ok.
>
> > + * event ^ |
> > + * enqueue| | event
> > + * | v dequeue
> > + * +---------------------------------------+
> > + * | |
> > + * | Crypto adapter |
> > + * | |
> > + * +---------------------------------------+
> > + * ^
> > + * | crypto
> > + * | enq/deq
> > + * v
> > + * +-------------+
> > + * | |
> > + * | Cryptodev |
> > + * | |
> > + * +-------------+
>
> Same as above comments for the diagram(i.e adding sequence number)
Ok
>
> > + *
> > + * In the ENQ_DEQ mode, application sends crypto operations as events
> > + to
> > + * the adapter which dequeues events and perform cryptodev operations.
> ^^^^^^^
> Not to the adapter, right?. applications sends to the eventdev through ports
> available through rte_event_crypto_adapter_event_port_get() eventdev port.
> Right?
>
> Please reword if it makes sense.
It is to the adapter through eventdev.
May be elaborating little more something like, application gets crypto adapter's
event port by rte_event_crypto_adapter_event_port_get() API.
Application links it's event queue to this event port and starts enqueuing crypto
operations as events. Adapter dequeue these events and submit the crypto operations
to the cryptodev.
Does this make sense?
>
> > + * The adapter dequeues crypto completions from cryptodev and enqueue
> > + * events to the event device.
> > + * In this mode, the application needs to specify the cryptodev ID
> > + * and queue pair ID (request information) needed to enqueue a crypto
> > + * operation in addition to the event information (response
> > + information)
> > + * needed to enqueue an event after the crypto operation has completed.
> > + *
> > + *
> > + * The event crypto adapter provides common APIs to configure the
> > + packet flow
> > + * from the crypto device to event devices for both SW and HW based
> transfers.
> > + * The crypto event adapter's functions are:
> > + * - rte_event_crypto_adapter_create_ext()
> > + * - rte_event_crypto_adapter_create()
> > + * - rte_event_crypto_adapter_free()
> > + * - rte_event_crypto_adapter_queue_pair_add()
> > + * - rte_event_crypto_adapter_queue_pair_del()
> > + * - rte_event_crypto_adapter_start()
> > + * - rte_event_crypto_adapter_stop()
> > + * - rte_event_crypto_adapter_stats_get()
> > + * - rte_event_crypto_adapter_stats_reset()
> > +
> > + * The applicaton creates an instance using
> > + rte_event_crypto_adapter_create()
>
> s/application/application
>
> > + * or rte_event_crypto_adapter_create_ext().
> > + *
> > + * Cryptodev queue pair addition/deletion is done using the
> > + * rte_event_crypto_adapter_queue_pair_xxx() APIs.
>
> I think, we can mention the connection of
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND capability
> here.
Ok
>
> > + *
> > + * The SW adapter or HW PMD uses rte_crypto_op::sess_type to decide
> > + whether
> > + * request/response(private) data is located in the crypto/security
> > + session
> > + * or at an offset in the rte_crypto_op.
> > + * The rte_crypto_op::private_data_offset provides an offset to
> > + locate the
> > + * request/response information in the rte_crypto_op.
> > + *
> > + * For session-based operations, the set and get API provides a
> > + mechanism for
> > + * an application to store and retrieve the data information stored
> > + * along with the crypto session.
>
> I think, we can mention the connection of
> RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA capability here.
Ok
>
> > +
> > + * For session-less mode, the adapter gets the private data
> > + information placed
> > + * along with the ``struct rte_crypto_op``.
> > + * The ``rte_crypto_op::private_data_offset`` indicates the start of
> > + private
> > + * data information. The offset is counted from the start of the
> > + rte_crypto_op
> > + * including initialization vector (IV).
> > + */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include <stdint.h>
> > +
> > +#include "rte_eventdev.h"
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this enum may change without prior notice
> > + *
> > + * Crypto event adapter mode
> > + */
> > +enum rte_event_crypto_adapter_mode {
> > + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
>
> Why to mark it as explicit '1' ?
Nothing specific. Have 0 & 1?
>
>
> > + /**< Start only dequeue part of crypto adapter.
> > + * Application submits crypto requests to the cryptodev.
> > + * Adapter only dequeues the crypto completions from cryptodev
> > + * and enqueue events to the eventdev.
>
> I think, you can mention the connection with below capabilities here.
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD
> and @see of those here.
This enum can be renamed to OP_NEW & OP_FWD.
So, the adapter will be configured with OP_NEW/OP_FWD mode.
>
>
> > + */
> > + RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ,
> > + /**< Start both enqueue & dequeue part of crypto adapter.
> > + * Application submits crypto requests as events to the crypto
> > + * adapter. Adapter submits crypto requests to the cryptodev
> > + * and crypto completions are enqueued back to the eventdev.
>
> IMO, You can add note when this mode will be used by application if device is
> not capable of RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD
> and application need ingress order maintenance or something like that.
Ok
>
> > + */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Crypto event request structure will be filled by application to
> > + * provide event request information to the adapter.
> > + */
> > +struct rte_event_crypto_request {
> > + uint8_t resv[8];
> > + /**< Overlaps with first 8 bytes of struct rte_event
> > + * that encode the response event information
>
> May be we could add more comments on application usage on updating struct
> rte_event based field updating for response event information.
Thought, struct name itself is self-explanatory. It will try to add some more comments.
>
> > + */
> > + uint16_t cdev_id;
> > + /**< cryptodev ID to be used */
> > + uint16_t queue_pair_id;
> > + /**< cryptodev queue pair ID to be used */
> > + uint32_t resv1;
>
> How about rsvd ? No strong opinion though.
resv is used as array. So resv1.
>
> I think, you can add, Valid when it adapter is in ENQ_DEQ mode
Ok
>
> > + /**< Reserved bits */
> > +};
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Crypto event metadata structure will be filled by application
> > + * to provide crypto request and event response information.
> > + *
> > + * If crypto events are enqueued using a HW mechanism, the cryptodev
> > + * PMD will use the event response information to set up the event
> > + * that is enqueued back to eventdev after completion of the crypto
> > + * operation. If the transfer is done by SW, event response
> > +information
> > + * will be used by the adapter.
> > + */
> > +union rte_event_crypto_metadata {
> > + struct rte_event_crypto_request request_info;
>
> I think, you can add, Provided by application for ENQ_DEQ mode
Ok
>
> > + struct rte_event response_info;
>
> I think, you can add, Provided by application for ENQ_DEQ and DEQ_ONLY
> mode.
Ok
>
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * Queue pair configuration structure containing event information.
> > + * @see
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
> > + */
> > +struct rte_event_crypto_queue_pair_conf {
> > + struct rte_event ev;
>
> MO, As Akhil said, we can pass struct rte_event directly.
Yes. I will remove this in next patch.
>
> > +};
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Create a new event crypto adapter with the specified identifier.
> > + * This function uses an internal configuration function that creates
> > +an event
> > + * port. This default function reconfigures the event device with an
> > + * additional event port and setups up the event port using the
> > +port_config
> > + * parameter passed into this function. In case the application needs
> > +more
> > + * control in configuration of the service, it should use the
> > + * rte_event_crypto_adapter_create_ext() version.
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @param dev_id
> > + * Event device identifier.
> > + *
> > + * @param port_config
> > + * Argument of type *rte_event_port_conf* that is passed to the
> > +conf_cb
> > + * function.
> > + *
> > + * @param mode
> > + * Flag to indicate to start dequeue only or both enqueue & dequeue.
> > + *
> > + * @return
> > + * - 0: Success
> > + * - <0: Error code on failure
> > + */
> > +int __rte_experimental
> > +rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
> > + struct rte_event_port_conf *port_config,
> > + enum rte_event_crypto_adapter_mode mode);
>
> - Detecting what to pass (RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY or
> RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ)
> in application need a lot checks based on capabilities, instead, How about
> passing whats been desired by the application by adding a new
> enum(RTE_EVENT_CRYPTO_ADAPTER_MODE_OP_NEW or
> RTE_EVENT_CRYPTO_ADAPTER_MODE_OP_FWD).
> and internally based on mode selected and the device capability, the common
> code can choose RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY in NEW or FWD
> mode vs RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ.
I will rename the mode to OP_NEW and OP_FWD.
>
> - We could add common code based API to return the exiting configured mode.
>
> enum rte_event_crypto_adapter_mode mode __rte_experimental
> rte_event_crypto_adapter_mode_get(uint8_t id, uint8_t dev_id);
Since the existing enum is renamed, this API will not be useful.
>
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Free an event crypto adapter
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @return
> > + * - 0: Success
> > + * - <0: Error code on failure, If the adapter still has queue pairs
> > + * added to it, the function returns -EBUSY.
> > + */
> > +int __rte_experimental
> > +rte_event_crypto_adapter_free(uint8_t id);
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Add a queue pair to an event crypto adapter.
> > + *
> > + * @param id
> > + * Adapter identifier.
> > + *
> > + * @param cdev_id
> > + * Cryptodev identifier.
> > + *
> > + * @param queue_pair_id
> > + * Cryptodev queue pair identifier. If queue_pair_id is set -1,
> > + * adapter adds all the pre configured queue pairs to the instance.
> > + *
> > + * @param conf
> > + * Additional configuration structure of type
> > + * *rte_event_crypto_queue_pair_conf*
>
> @see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
Ok
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,1/6] eventdev: introduce event crypto adapter
2018-05-03 6:03 ` Gujjar, Abhinandan S
@ 2018-05-03 9:02 ` Jerin Jacob
0 siblings, 0 replies; 29+ messages in thread
From: Jerin Jacob @ 2018-05-03 9:02 UTC (permalink / raw)
To: Gujjar, Abhinandan S
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
-----Original Message-----
> Date: Thu, 3 May 2018 06:03:01 +0000
> From: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
> "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, "dev@dpdk.org"
> <dev@dpdk.org>, "Vangati, Narender" <narender.vangati@intel.com>, "Rao,
> Nikhil" <nikhil.rao@intel.com>, "Eads, Gage" <gage.eads@intel.com>
> Subject: RE: [v2,1/6] eventdev: introduce event crypto adapter
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > Sent: Sunday, April 29, 2018 9:39 PM
> > To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> > Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> > Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> > Eads, Gage <gage.eads@intel.com>
> > Subject: Re: [v2,1/6] eventdev: introduce event crypto adapter
> >
> > -----Original Message-----
> > > Date: Tue, 24 Apr 2018 18:13:22 +0530
> > > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > > akhil.goyal@nxp.com, dev@dpdk.org
> > > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > > nikhil.rao@intel.com, gage.eads@intel.com
> > > Subject: [v2,1/6] eventdev: introduce event crypto adapter
> > > X-Mailer: git-send-email 1.9.1
> > >
> > > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > > ---
> > > lib/librte_eventdev/rte_event_crypto_adapter.h | 532
> > > +++++++++++++++++++++++++
> > > 1 file changed, 532 insertions(+)
> > > create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.h
> > >
> > > diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.h
> > > b/lib/librte_eventdev/rte_event_crypto_adapter.h
> > > new file mode 100644
> > > index 0000000..aa4f32c
> > > --- /dev/null
> > > +++ b/lib/librte_eventdev/rte_event_crypto_adapter.h
> > > @@ -0,0 +1,532 @@
> > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > + * Copyright(c) 2017-2018 Intel Corporation */
> > > +
> > > +#ifndef _RTE_EVENT_CRYPTO_ADAPTER_
> > > +#define _RTE_EVENT_CRYPTO_ADAPTER_
> >
> > Please reword if it makes sense.
> It is to the adapter through eventdev.
> May be elaborating little more something like, application gets crypto adapter's
> event port by rte_event_crypto_adapter_event_port_get() API.
> Application links it's event queue to this event port and starts enqueuing crypto
> operations as events. Adapter dequeue these events and submit the crypto operations
> to the cryptodev.
>
> Does this make sense?
Yes
> > > + RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY = 1,
> >
> > Why to mark it as explicit '1' ?
> Nothing specific. Have 0 & 1?
Let have 0 then so that enum you don't need to specify '0' explicit as
enum starts from 0
Thanks for the comments. Looks like we have sorted out all the issues.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for crypto adapter
2018-04-24 12:43 [dpdk-dev] [v2,0/6] eventdev: cover letter - crypto adapter Abhinandan Gujjar
2018-04-24 12:43 ` [dpdk-dev] [v2,1/6] eventdev: introduce event " Abhinandan Gujjar
@ 2018-04-24 12:43 ` Abhinandan Gujjar
2018-04-29 16:14 ` Jerin Jacob
2018-04-24 12:43 ` [dpdk-dev] [v2,3/6] eventdev: add crypto adapter implementation Abhinandan Gujjar
` (3 subsequent siblings)
5 siblings, 1 reply; 29+ messages in thread
From: Abhinandan Gujjar @ 2018-04-24 12:43 UTC (permalink / raw)
To: jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, abhinandan.gujjar, nikhil.rao, gage.eads
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
---
drivers/event/sw/sw_evdev.c | 13 +++
lib/librte_eventdev/rte_eventdev.c | 25 +++++
lib/librte_eventdev/rte_eventdev.h | 52 +++++++++
lib/librte_eventdev/rte_eventdev_pmd.h | 189 +++++++++++++++++++++++++++++++++
4 files changed, 279 insertions(+)
diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
index dcb6551..10f0e1a 100644
--- a/drivers/event/sw/sw_evdev.c
+++ b/drivers/event/sw/sw_evdev.c
@@ -480,6 +480,17 @@
return 0;
}
+static int
+sw_crypto_adapter_caps_get(const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev,
+ uint32_t *caps)
+{
+ RTE_SET_USED(dev);
+ RTE_SET_USED(cdev);
+ *caps = RTE_EVENT_CRYPTO_ADAPTER_SW_CAP;
+ return 0;
+}
+
static void
sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
{
@@ -809,6 +820,8 @@ static int32_t sw_sched_service_func(void *args)
.timer_adapter_caps_get = sw_timer_adapter_caps_get,
+ .crypto_adapter_caps_get = sw_crypto_adapter_caps_get,
+
.xstats_get = sw_xstats_get,
.xstats_get_names = sw_xstats_get_names,
.xstats_get_by_name = sw_xstats_get_by_name,
diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
index 3f016f4..7ca9fd1 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -29,6 +29,8 @@
#include <rte_malloc.h>
#include <rte_errno.h>
#include <rte_ethdev.h>
+#include <rte_cryptodev.h>
+#include <rte_cryptodev_pmd.h>
#include "rte_eventdev.h"
#include "rte_eventdev_pmd.h"
@@ -145,6 +147,29 @@
: 0;
}
+int __rte_experimental
+rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
+ uint32_t *caps)
+{
+ struct rte_eventdev *dev;
+ struct rte_cryptodev *cdev;
+
+ RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ if (!rte_cryptodev_pmd_is_valid_dev(cdev_id))
+ return -EINVAL;
+
+ dev = &rte_eventdevs[dev_id];
+ cdev = rte_cryptodev_pmd_get_dev(cdev_id);
+
+ if (caps == NULL)
+ return -EINVAL;
+ *caps = 0;
+
+ return dev->dev_ops->crypto_adapter_caps_get ?
+ (*dev->dev_ops->crypto_adapter_caps_get)
+ (dev, cdev, caps) : -ENOTSUP;
+}
+
static inline int
rte_event_dev_queue_config(struct rte_eventdev *dev, uint8_t nb_queues)
{
diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
index 8297f24..9822747 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -8,6 +8,8 @@
#ifndef _RTE_EVENTDEV_H_
#define _RTE_EVENTDEV_H_
+#include <rte_compat.h>
+
/**
* @file
*
@@ -1135,6 +1137,56 @@ struct rte_event {
int __rte_experimental
rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t *caps);
+/* Crypto adapter capability bitmap flag */
+#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW 0x1
+/**< Flag indicates HW is capable of generating events.
+ * Cryptodev will send packets to the event device as new events
+ * using an internal event port.
+ */
+
+#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD 0x2
+/**< Flag indicates HW is capable of generating events.
+ * Cryptodev will send packets to the event device as forwarded event
+ * using an internal event port.
+ */
+
+#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND 0x4
+/**< Flag indicates HW is capable of mapping crypto queue pair to
+ * event queue.
+ */
+
+#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8
+/**< Flag indicates HW/SW suports a mechanism to store and retrieve
+ * the private data information along with the crypto session.
+ */
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Retrieve the event device's crypto adapter capabilities for the
+ * specified cryptodev device
+ *
+ * @param dev_id
+ * The identifier of the device.
+ *
+ * @param cdev_id
+ * The identifier of the cryptodev device.
+ *
+ * @param[out] caps
+ * A pointer to memory filled with event adapter capabilities.
+ * It is expected to be pre-allocated & initialized by caller.
+ *
+ * @return
+ * - 0: Success, driver provides event adapter capabilities for the
+ * cryptodev device.
+ * - <0: Error code returned by the driver function.
+ *
+ */
+int __rte_experimental
+rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
+ uint32_t *caps);
+
struct rte_eventdev_ops;
struct rte_eventdev;
diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h b/lib/librte_eventdev/rte_eventdev_pmd.h
index 2dcb528..739b984 100644
--- a/lib/librte_eventdev/rte_eventdev_pmd.h
+++ b/lib/librte_eventdev/rte_eventdev_pmd.h
@@ -70,6 +70,9 @@
((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) | \
(RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ))
+#define RTE_EVENT_CRYPTO_ADAPTER_SW_CAP \
+ RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
+
/**< Ethernet Rx adapter cap to return If the packet transfers from
* the ethdev to eventdev use a SW service function
*/
@@ -617,6 +620,177 @@ typedef int (*eventdev_eth_rx_adapter_stats_reset)
*/
typedef int (*eventdev_selftest)(void);
+
+struct rte_cryptodev;
+struct rte_event_crypto_queue_pair_conf *conf;
+
+/**
+ * This API may change without prior notice
+ *
+ * Retrieve the event device's crypto adapter capabilities for the
+ * specified cryptodev
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * cryptodev pointer
+ *
+ * @param[out] caps
+ * A pointer to memory filled with event adapter capabilities.
+ * It is expected to be pre-allocated & initialized by caller.
+ *
+ * @return
+ * - 0: Success, driver provides event adapter capabilities for the
+ * cryptodev.
+ * - <0: Error code returned by the driver function.
+ *
+ */
+typedef int (*eventdev_crypto_adapter_caps_get_t)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev,
+ uint32_t *caps);
+
+/**
+ * This API may change without prior notice
+ *
+ * Add crypto queue pair to event device. This callback is invoked if
+ * the caps returned from rte_event_crypto_adapter_caps_get(, cdev_id)
+ * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * cryptodev pointer
+ *
+ * @param queue_pair_id
+ * cryptodev queue pair identifier.
+ *
+ * @param conf
+ * Additional configuration structure of type
+ * *rte_event_crypto_queue_pair_conf*.
+ * This structure will have a valid value for only those HW PMDs supporting
+ * @see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND capability.
+ *
+ * @return
+ * - 0: Success, cryptodev queue pair added successfully.
+ * - <0: Error code returned by the driver function.
+ *
+ */
+typedef int (*eventdev_crypto_adapter_queue_pair_add_t)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev,
+ int32_t queue_pair_id,
+ const struct rte_event_crypto_queue_pair_conf *conf);
+
+
+/**
+ * This API may change without prior notice
+ *
+ * Delete crypto queue pair to event device. This callback is invoked if
+ * the caps returned from rte_event_crypto_adapter_caps_get(, cdev_id)
+ * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * cryptodev pointer
+ *
+ * @param queue_pair_id
+ * cryptodev queue pair identifier.
+ *
+ * @return
+ * - 0: Success, cryptodev queue pair deleted successfully.
+ * - <0: Error code returned by the driver function.
+ *
+ */
+typedef int (*eventdev_crypto_adapter_queue_pair_del_t)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev,
+ int32_t queue_pair_id);
+
+/**
+ * Start crypto adapter. This callback is invoked if
+ * the caps returned from rte_event_crypto_adapter_caps_get(.., cdev_id)
+ * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set and queue pairs
+ * from cdev_id have been added to the event device.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * Crypto device pointer
+ *
+ * @return
+ * - 0: Success, crypto adapter started successfully.
+ * - <0: Error code returned by the driver function.
+ */
+typedef int (*eventdev_crypto_adapter_start_t)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev);
+
+/**
+ * Stop crypto adapter. This callback is invoked if
+ * the caps returned from rte_event_crypto_adapter_caps_get(.., cdev_id)
+ * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set and queue pairs
+ * from cdev_id have been added to the event device.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * Crypto device pointer
+ *
+ * @return
+ * - 0: Success, crypto adapter stopped successfully.
+ * - <0: Error code returned by the driver function.
+ */
+typedef int (*eventdev_crypto_adapter_stop_t)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev);
+
+struct rte_event_crypto_adapter_stats;
+
+/**
+ * Retrieve crypto adapter statistics.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * Crypto device pointer
+ *
+ * @param[out] stats
+ * Pointer to stats structure
+ *
+ * @return
+ * Return 0 on success.
+ */
+
+typedef int (*eventdev_crypto_adapter_stats_get)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev,
+ struct rte_event_crypto_adapter_stats *stats);
+
+/**
+ * Reset crypto adapter statistics.
+ *
+ * @param dev
+ * Event device pointer
+ *
+ * @param cdev
+ * Crypto device pointer
+ *
+ * @return
+ * Return 0 on success.
+ */
+
+typedef int (*eventdev_crypto_adapter_stats_reset)
+ (const struct rte_eventdev *dev,
+ const struct rte_cryptodev *cdev);
+
/** Event device operations function pointer table */
struct rte_eventdev_ops {
eventdev_info_get_t dev_infos_get; /**< Get device info. */
@@ -675,6 +849,21 @@ struct rte_eventdev_ops {
eventdev_timer_adapter_caps_get_t timer_adapter_caps_get;
/**< Get timer adapter capabilities */
+ eventdev_crypto_adapter_caps_get_t crypto_adapter_caps_get;
+ /**< Get crypto adapter capabilities */
+ eventdev_crypto_adapter_queue_pair_add_t crypto_adapter_queue_pair_add;
+ /**< Add queue pair to crypto adapter */
+ eventdev_crypto_adapter_queue_pair_del_t crypto_adapter_queue_pair_del;
+ /**< Delete queue pair from crypto adapter */
+ eventdev_crypto_adapter_start_t crypto_adapter_start;
+ /**< Start crypto adapter */
+ eventdev_crypto_adapter_stop_t crypto_adapter_stop;
+ /**< Stop crypto adapter */
+ eventdev_crypto_adapter_stats_get crypto_adapter_stats_get;
+ /**< Get crypto stats */
+ eventdev_crypto_adapter_stats_reset crypto_adapter_stats_reset;
+ /**< Reset crypto stats */
+
eventdev_selftest dev_selftest;
/**< Start eventdev Selftest */
--
1.9.1
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for crypto adapter
2018-04-24 12:43 ` [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for " Abhinandan Gujjar
@ 2018-04-29 16:14 ` Jerin Jacob
2018-04-30 11:15 ` Gujjar, Abhinandan S
0 siblings, 1 reply; 29+ messages in thread
From: Jerin Jacob @ 2018-04-29 16:14 UTC (permalink / raw)
To: Abhinandan Gujjar
Cc: hemant.agrawal, akhil.goyal, dev, narender.vangati, nikhil.rao,
gage.eads
-----Original Message-----
> Date: Tue, 24 Apr 2018 18:13:23 +0530
> From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> akhil.goyal@nxp.com, dev@dpdk.org
> CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> nikhil.rao@intel.com, gage.eads@intel.com
> Subject: [v2,2/6] eventdev: add APIs and PMD callbacks for crypto adapter
> X-Mailer: git-send-email 1.9.1
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> drivers/event/sw/sw_evdev.c | 13 +++
> lib/librte_eventdev/rte_eventdev.c | 25 +++++
> lib/librte_eventdev/rte_eventdev.h | 52 +++++++++
> lib/librte_eventdev/rte_eventdev_pmd.h | 189 +++++++++++++++++++++++++++++++++
> 4 files changed, 279 insertions(+)
>
> diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
> index dcb6551..10f0e1a 100644
> --- a/drivers/event/sw/sw_evdev.c
> +++ b/drivers/event/sw/sw_evdev.c
> @@ -480,6 +480,17 @@
> return 0;
> }
>
> +static int
> +sw_crypto_adapter_caps_get(const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev,
> + uint32_t *caps)
> +{
> + RTE_SET_USED(dev);
> + RTE_SET_USED(cdev);
> + *caps = RTE_EVENT_CRYPTO_ADAPTER_SW_CAP;
> + return 0;
> +}
> +
> static void
> sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info *info)
> {
> @@ -809,6 +820,8 @@ static int32_t sw_sched_service_func(void *args)
>
> .timer_adapter_caps_get = sw_timer_adapter_caps_get,
>
> + .crypto_adapter_caps_get = sw_crypto_adapter_caps_get,
> +
> .xstats_get = sw_xstats_get,
> .xstats_get_names = sw_xstats_get_names,
> .xstats_get_by_name = sw_xstats_get_by_name,
> diff --git a/lib/librte_eventdev/rte_eventdev.c b/lib/librte_eventdev/rte_eventdev.c
> index 3f016f4..7ca9fd1 100644
> --- a/lib/librte_eventdev/rte_eventdev.c
> +++ b/lib/librte_eventdev/rte_eventdev.c
> @@ -29,6 +29,8 @@
> #include <rte_malloc.h>
> #include <rte_errno.h>
> #include <rte_ethdev.h>
> +#include <rte_cryptodev.h>
> +#include <rte_cryptodev_pmd.h>
>
> #include "rte_eventdev.h"
> #include "rte_eventdev_pmd.h"
> @@ -145,6 +147,29 @@
> : 0;
> }
>
> +int __rte_experimental
> +rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
> + uint32_t *caps)
> +{
> + struct rte_eventdev *dev;
> + struct rte_cryptodev *cdev;
> +
> + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
> + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id))
> + return -EINVAL;
> +
> + dev = &rte_eventdevs[dev_id];
> + cdev = rte_cryptodev_pmd_get_dev(cdev_id);
> +
> + if (caps == NULL)
> + return -EINVAL;
> + *caps = 0;
> +
> + return dev->dev_ops->crypto_adapter_caps_get ?
> + (*dev->dev_ops->crypto_adapter_caps_get)
> + (dev, cdev, caps) : -ENOTSUP;
> +}
> +
> static inline int
> rte_event_dev_queue_config(struct rte_eventdev *dev, uint8_t nb_queues)
> {
> diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h
> index 8297f24..9822747 100644
> --- a/lib/librte_eventdev/rte_eventdev.h
> +++ b/lib/librte_eventdev/rte_eventdev.h
> @@ -8,6 +8,8 @@
> #ifndef _RTE_EVENTDEV_H_
> #define _RTE_EVENTDEV_H_
>
> +#include <rte_compat.h>
> +
> /**
> * @file
> *
> @@ -1135,6 +1137,56 @@ struct rte_event {
> int __rte_experimental
> rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t *caps);
>
> +/* Crypto adapter capability bitmap flag */
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW 0x1
> +/**< Flag indicates HW is capable of generating events.
events in RTE_EVENT_OP_NEW enqueue operation
> + * Cryptodev will send packets to the event device as new events
> + * using an internal event port.
> + */
> +
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD 0x2
> +/**< Flag indicates HW is capable of generating events.
events in RTE_EVENT_OP_FWD enqueue operation
> + * Cryptodev will send packets to the event device as forwarded event
> + * using an internal event port.
> + */
> +
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND 0x4
> +/**< Flag indicates HW is capable of mapping crypto queue pair to
> + * event queue.
> + */
> +
> +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8
> +/**< Flag indicates HW/SW suports a mechanism to store and retrieve
> + * the private data information along with the crypto session.
> + */
> +
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Retrieve the event device's crypto adapter capabilities for the
> + * specified cryptodev device
> + *
> + * @param dev_id
> + * The identifier of the device.
> + *
> + * @param cdev_id
> + * The identifier of the cryptodev device.
> + *
> + * @param[out] caps
> + * A pointer to memory filled with event adapter capabilities.
> + * It is expected to be pre-allocated & initialized by caller.
> + *
> + * @return
> + * - 0: Success, driver provides event adapter capabilities for the
> + * cryptodev device.
> + * - <0: Error code returned by the driver function.
> + *
> + */
> +int __rte_experimental
> +rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
> + uint32_t *caps);
> +
> struct rte_eventdev_ops;
> struct rte_eventdev;
>
> diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h b/lib/librte_eventdev/rte_eventdev_pmd.h
> index 2dcb528..739b984 100644
> --- a/lib/librte_eventdev/rte_eventdev_pmd.h
> +++ b/lib/librte_eventdev/rte_eventdev_pmd.h
> @@ -70,6 +70,9 @@
> ((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) | \
> (RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ))
>
> +#define RTE_EVENT_CRYPTO_ADAPTER_SW_CAP \
> + RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
> +
> /**< Ethernet Rx adapter cap to return If the packet transfers from
> * the ethdev to eventdev use a SW service function
> */
> @@ -617,6 +620,177 @@ typedef int (*eventdev_eth_rx_adapter_stats_reset)
> */
> typedef int (*eventdev_selftest)(void);
>
> +
> +struct rte_cryptodev;
> +struct rte_event_crypto_queue_pair_conf *conf;
Can we get rid of this conf global variable?
> +
> +/**
> + * This API may change without prior notice
> + *
> + * Retrieve the event device's crypto adapter capabilities for the
> + * specified cryptodev
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * cryptodev pointer
> + *
> + * @param[out] caps
> + * A pointer to memory filled with event adapter capabilities.
> + * It is expected to be pre-allocated & initialized by caller.
> + *
> + * @return
> + * - 0: Success, driver provides event adapter capabilities for the
> + * cryptodev.
> + * - <0: Error code returned by the driver function.
> + *
> + */
> +typedef int (*eventdev_crypto_adapter_caps_get_t)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev,
> + uint32_t *caps);
> +
> +/**
> + * This API may change without prior notice
> + *
> + * Add crypto queue pair to event device. This callback is invoked if
> + * the caps returned from rte_event_crypto_adapter_caps_get(, cdev_id)
> + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * cryptodev pointer
> + *
> + * @param queue_pair_id
> + * cryptodev queue pair identifier.
> + *
> + * @param conf
> + * Additional configuration structure of type
> + * *rte_event_crypto_queue_pair_conf*.
> + * This structure will have a valid value for only those HW PMDs supporting
> + * @see RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND capability.
> + *
> + * @return
> + * - 0: Success, cryptodev queue pair added successfully.
> + * - <0: Error code returned by the driver function.
> + *
> + */
> +typedef int (*eventdev_crypto_adapter_queue_pair_add_t)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev,
> + int32_t queue_pair_id,
> + const struct rte_event_crypto_queue_pair_conf *conf);
> +
> +
> +/**
> + * This API may change without prior notice
> + *
> + * Delete crypto queue pair to event device. This callback is invoked if
> + * the caps returned from rte_event_crypto_adapter_caps_get(, cdev_id)
> + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * cryptodev pointer
> + *
> + * @param queue_pair_id
> + * cryptodev queue pair identifier.
> + *
> + * @return
> + * - 0: Success, cryptodev queue pair deleted successfully.
> + * - <0: Error code returned by the driver function.
> + *
> + */
> +typedef int (*eventdev_crypto_adapter_queue_pair_del_t)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev,
> + int32_t queue_pair_id);
> +
> +/**
> + * Start crypto adapter. This callback is invoked if
> + * the caps returned from rte_event_crypto_adapter_caps_get(.., cdev_id)
> + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set and queue pairs
> + * from cdev_id have been added to the event device.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * Crypto device pointer
> + *
> + * @return
> + * - 0: Success, crypto adapter started successfully.
> + * - <0: Error code returned by the driver function.
> + */
> +typedef int (*eventdev_crypto_adapter_start_t)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev);
> +
> +/**
> + * Stop crypto adapter. This callback is invoked if
> + * the caps returned from rte_event_crypto_adapter_caps_get(.., cdev_id)
> + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set and queue pairs
> + * from cdev_id have been added to the event device.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * Crypto device pointer
> + *
> + * @return
> + * - 0: Success, crypto adapter stopped successfully.
> + * - <0: Error code returned by the driver function.
> + */
> +typedef int (*eventdev_crypto_adapter_stop_t)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev);
> +
> +struct rte_event_crypto_adapter_stats;
> +
> +/**
> + * Retrieve crypto adapter statistics.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * Crypto device pointer
> + *
> + * @param[out] stats
> + * Pointer to stats structure
> + *
> + * @return
> + * Return 0 on success.
> + */
> +
> +typedef int (*eventdev_crypto_adapter_stats_get)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev,
> + struct rte_event_crypto_adapter_stats *stats);
> +
> +/**
> + * Reset crypto adapter statistics.
> + *
> + * @param dev
> + * Event device pointer
> + *
> + * @param cdev
> + * Crypto device pointer
> + *
> + * @return
> + * Return 0 on success.
> + */
> +
> +typedef int (*eventdev_crypto_adapter_stats_reset)
> + (const struct rte_eventdev *dev,
> + const struct rte_cryptodev *cdev);
> +
> /** Event device operations function pointer table */
> struct rte_eventdev_ops {
> eventdev_info_get_t dev_infos_get; /**< Get device info. */
> @@ -675,6 +849,21 @@ struct rte_eventdev_ops {
> eventdev_timer_adapter_caps_get_t timer_adapter_caps_get;
> /**< Get timer adapter capabilities */
>
> + eventdev_crypto_adapter_caps_get_t crypto_adapter_caps_get;
> + /**< Get crypto adapter capabilities */
> + eventdev_crypto_adapter_queue_pair_add_t crypto_adapter_queue_pair_add;
> + /**< Add queue pair to crypto adapter */
> + eventdev_crypto_adapter_queue_pair_del_t crypto_adapter_queue_pair_del;
> + /**< Delete queue pair from crypto adapter */
> + eventdev_crypto_adapter_start_t crypto_adapter_start;
> + /**< Start crypto adapter */
> + eventdev_crypto_adapter_stop_t crypto_adapter_stop;
> + /**< Stop crypto adapter */
> + eventdev_crypto_adapter_stats_get crypto_adapter_stats_get;
> + /**< Get crypto stats */
> + eventdev_crypto_adapter_stats_reset crypto_adapter_stats_reset;
> + /**< Reset crypto stats */
> +
> eventdev_selftest dev_selftest;
> /**< Start eventdev Selftest */
>
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for crypto adapter
2018-04-29 16:14 ` Jerin Jacob
@ 2018-04-30 11:15 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-30 11:15 UTC (permalink / raw)
To: Jerin Jacob
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Sunday, April 29, 2018 9:44 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> Eads, Gage <gage.eads@intel.com>
> Subject: Re: [v2,2/6] eventdev: add APIs and PMD callbacks for crypto adapter
>
> -----Original Message-----
> > Date: Tue, 24 Apr 2018 18:13:23 +0530
> > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > akhil.goyal@nxp.com, dev@dpdk.org
> > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > nikhil.rao@intel.com, gage.eads@intel.com
> > Subject: [v2,2/6] eventdev: add APIs and PMD callbacks for crypto
> > adapter
> > X-Mailer: git-send-email 1.9.1
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > drivers/event/sw/sw_evdev.c | 13 +++
> > lib/librte_eventdev/rte_eventdev.c | 25 +++++
> > lib/librte_eventdev/rte_eventdev.h | 52 +++++++++
> > lib/librte_eventdev/rte_eventdev_pmd.h | 189
> > +++++++++++++++++++++++++++++++++
> > 4 files changed, 279 insertions(+)
> >
> > diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c
> > index dcb6551..10f0e1a 100644
> > --- a/drivers/event/sw/sw_evdev.c
> > +++ b/drivers/event/sw/sw_evdev.c
> > @@ -480,6 +480,17 @@
> > return 0;
> > }
> >
> > +static int
> > +sw_crypto_adapter_caps_get(const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev,
> > + uint32_t *caps)
> > +{
> > + RTE_SET_USED(dev);
> > + RTE_SET_USED(cdev);
> > + *caps = RTE_EVENT_CRYPTO_ADAPTER_SW_CAP;
> > + return 0;
> > +}
> > +
> > static void
> > sw_info_get(struct rte_eventdev *dev, struct rte_event_dev_info
> > *info) { @@ -809,6 +820,8 @@ static int32_t
> > sw_sched_service_func(void *args)
> >
> > .timer_adapter_caps_get =
> sw_timer_adapter_caps_get,
> >
> > + .crypto_adapter_caps_get =
> sw_crypto_adapter_caps_get,
> > +
> > .xstats_get = sw_xstats_get,
> > .xstats_get_names = sw_xstats_get_names,
> > .xstats_get_by_name = sw_xstats_get_by_name, diff --
> git
> > a/lib/librte_eventdev/rte_eventdev.c
> > b/lib/librte_eventdev/rte_eventdev.c
> > index 3f016f4..7ca9fd1 100644
> > --- a/lib/librte_eventdev/rte_eventdev.c
> > +++ b/lib/librte_eventdev/rte_eventdev.c
> > @@ -29,6 +29,8 @@
> > #include <rte_malloc.h>
> > #include <rte_errno.h>
> > #include <rte_ethdev.h>
> > +#include <rte_cryptodev.h>
> > +#include <rte_cryptodev_pmd.h>
> >
> > #include "rte_eventdev.h"
> > #include "rte_eventdev_pmd.h"
> > @@ -145,6 +147,29 @@
> > : 0;
> > }
> >
> > +int __rte_experimental
> > +rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
> > + uint32_t *caps)
> > +{
> > + struct rte_eventdev *dev;
> > + struct rte_cryptodev *cdev;
> > +
> > + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
> > + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id))
> > + return -EINVAL;
> > +
> > + dev = &rte_eventdevs[dev_id];
> > + cdev = rte_cryptodev_pmd_get_dev(cdev_id);
> > +
> > + if (caps == NULL)
> > + return -EINVAL;
> > + *caps = 0;
> > +
> > + return dev->dev_ops->crypto_adapter_caps_get ?
> > + (*dev->dev_ops->crypto_adapter_caps_get)
> > + (dev, cdev, caps) : -ENOTSUP;
> > +}
> > +
> > static inline int
> > rte_event_dev_queue_config(struct rte_eventdev *dev, uint8_t
> > nb_queues) { diff --git a/lib/librte_eventdev/rte_eventdev.h
> > b/lib/librte_eventdev/rte_eventdev.h
> > index 8297f24..9822747 100644
> > --- a/lib/librte_eventdev/rte_eventdev.h
> > +++ b/lib/librte_eventdev/rte_eventdev.h
> > @@ -8,6 +8,8 @@
> > #ifndef _RTE_EVENTDEV_H_
> > #define _RTE_EVENTDEV_H_
> >
> > +#include <rte_compat.h>
> > +
> > /**
> > * @file
> > *
> > @@ -1135,6 +1137,56 @@ struct rte_event { int __rte_experimental
> > rte_event_timer_adapter_caps_get(uint8_t dev_id, uint32_t *caps);
> >
> > +/* Crypto adapter capability bitmap flag */
> > +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW
> 0x1
> > +/**< Flag indicates HW is capable of generating events.
>
> events in RTE_EVENT_OP_NEW enqueue operation
Ok
>
> > + * Cryptodev will send packets to the event device as new events
> > + * using an internal event port.
> > + */
> > +
> > +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD
> 0x2
> > +/**< Flag indicates HW is capable of generating events.
>
> events in RTE_EVENT_OP_FWD enqueue operation
Ok
>
> > + * Cryptodev will send packets to the event device as forwarded event
> > + * using an internal event port.
> > + */
> > +
> > +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND
> 0x4
> > +/**< Flag indicates HW is capable of mapping crypto queue pair to
> > + * event queue.
> > + */
> > +
> > +#define RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA 0x8
> > +/**< Flag indicates HW/SW suports a mechanism to store and retrieve
> > + * the private data information along with the crypto session.
> > + */
> > +
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Retrieve the event device's crypto adapter capabilities for the
> > + * specified cryptodev device
> > + *
> > + * @param dev_id
> > + * The identifier of the device.
> > + *
> > + * @param cdev_id
> > + * The identifier of the cryptodev device.
> > + *
> > + * @param[out] caps
> > + * A pointer to memory filled with event adapter capabilities.
> > + * It is expected to be pre-allocated & initialized by caller.
> > + *
> > + * @return
> > + * - 0: Success, driver provides event adapter capabilities for the
> > + * cryptodev device.
> > + * - <0: Error code returned by the driver function.
> > + *
> > + */
> > +int __rte_experimental
> > +rte_event_crypto_adapter_caps_get(uint8_t dev_id, uint8_t cdev_id,
> > + uint32_t *caps);
> > +
> > struct rte_eventdev_ops;
> > struct rte_eventdev;
> >
> > diff --git a/lib/librte_eventdev/rte_eventdev_pmd.h
> > b/lib/librte_eventdev/rte_eventdev_pmd.h
> > index 2dcb528..739b984 100644
> > --- a/lib/librte_eventdev/rte_eventdev_pmd.h
> > +++ b/lib/librte_eventdev/rte_eventdev_pmd.h
> > @@ -70,6 +70,9 @@
> > ((RTE_EVENT_ETH_RX_ADAPTER_CAP_OVERRIDE_FLOW_ID) | \
> >
> (RTE_EVENT_ETH_RX_ADAPTER_CAP_MULTI_EVENTQ))
> >
> > +#define RTE_EVENT_CRYPTO_ADAPTER_SW_CAP \
> > + RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
> > +
> > /**< Ethernet Rx adapter cap to return If the packet transfers from
> > * the ethdev to eventdev use a SW service function
> > */
> > @@ -617,6 +620,177 @@ typedef int
> (*eventdev_eth_rx_adapter_stats_reset)
> > */
> > typedef int (*eventdev_selftest)(void);
> >
> > +
> > +struct rte_cryptodev;
> > +struct rte_event_crypto_queue_pair_conf *conf;
>
> Can we get rid of this conf global variable?
Sure, I will replace the conf with rte_event to configure qps.
>
> > +
> > +/**
> > + * This API may change without prior notice
> > + *
> > + * Retrieve the event device's crypto adapter capabilities for the
> > + * specified cryptodev
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * cryptodev pointer
> > + *
> > + * @param[out] caps
> > + * A pointer to memory filled with event adapter capabilities.
> > + * It is expected to be pre-allocated & initialized by caller.
> > + *
> > + * @return
> > + * - 0: Success, driver provides event adapter capabilities for the
> > + * cryptodev.
> > + * - <0: Error code returned by the driver function.
> > + *
> > + */
> > +typedef int (*eventdev_crypto_adapter_caps_get_t)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev,
> > + uint32_t *caps);
> > +
> > +/**
> > + * This API may change without prior notice
> > + *
> > + * Add crypto queue pair to event device. This callback is invoked if
> > + * the caps returned from rte_event_crypto_adapter_caps_get(,
> > +cdev_id)
> > + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set.
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * cryptodev pointer
> > + *
> > + * @param queue_pair_id
> > + * cryptodev queue pair identifier.
> > + *
> > + * @param conf
> > + * Additional configuration structure of type
> > + * *rte_event_crypto_queue_pair_conf*.
> > + * This structure will have a valid value for only those HW PMDs
> > +supporting
> > + * @see
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND capability.
Ok
> > + *
> > + * @return
> > + * - 0: Success, cryptodev queue pair added successfully.
> > + * - <0: Error code returned by the driver function.
> > + *
> > + */
> > +typedef int (*eventdev_crypto_adapter_queue_pair_add_t)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev,
> > + int32_t queue_pair_id,
> > + const struct rte_event_crypto_queue_pair_conf
> *conf);
> > +
> > +
> > +/**
> > + * This API may change without prior notice
> > + *
> > + * Delete crypto queue pair to event device. This callback is invoked
> > +if
> > + * the caps returned from rte_event_crypto_adapter_caps_get(,
> > +cdev_id)
> > + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set.
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * cryptodev pointer
> > + *
> > + * @param queue_pair_id
> > + * cryptodev queue pair identifier.
> > + *
> > + * @return
> > + * - 0: Success, cryptodev queue pair deleted successfully.
> > + * - <0: Error code returned by the driver function.
> > + *
> > + */
> > +typedef int (*eventdev_crypto_adapter_queue_pair_del_t)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev,
> > + int32_t queue_pair_id);
> > +
> > +/**
> > + * Start crypto adapter. This callback is invoked if
> > + * the caps returned from rte_event_crypto_adapter_caps_get(..,
> > +cdev_id)
> > + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set and
> queue
> > +pairs
> > + * from cdev_id have been added to the event device.
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * Crypto device pointer
> > + *
> > + * @return
> > + * - 0: Success, crypto adapter started successfully.
> > + * - <0: Error code returned by the driver function.
> > + */
> > +typedef int (*eventdev_crypto_adapter_start_t)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev);
> > +
> > +/**
> > + * Stop crypto adapter. This callback is invoked if
> > + * the caps returned from rte_event_crypto_adapter_caps_get(..,
> > +cdev_id)
> > + * has RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_* set and
> queue
> > +pairs
> > + * from cdev_id have been added to the event device.
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * Crypto device pointer
> > + *
> > + * @return
> > + * - 0: Success, crypto adapter stopped successfully.
> > + * - <0: Error code returned by the driver function.
> > + */
> > +typedef int (*eventdev_crypto_adapter_stop_t)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev);
> > +
> > +struct rte_event_crypto_adapter_stats;
> > +
> > +/**
> > + * Retrieve crypto adapter statistics.
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * Crypto device pointer
> > + *
> > + * @param[out] stats
> > + * Pointer to stats structure
> > + *
> > + * @return
> > + * Return 0 on success.
> > + */
> > +
> > +typedef int (*eventdev_crypto_adapter_stats_get)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev,
> > + struct rte_event_crypto_adapter_stats *stats);
> > +
> > +/**
> > + * Reset crypto adapter statistics.
> > + *
> > + * @param dev
> > + * Event device pointer
> > + *
> > + * @param cdev
> > + * Crypto device pointer
> > + *
> > + * @return
> > + * Return 0 on success.
> > + */
> > +
> > +typedef int (*eventdev_crypto_adapter_stats_reset)
> > + (const struct rte_eventdev *dev,
> > + const struct rte_cryptodev *cdev);
> > +
> > /** Event device operations function pointer table */ struct
> > rte_eventdev_ops {
> > eventdev_info_get_t dev_infos_get; /**< Get device info. */
> > @@ -675,6 +849,21 @@ struct rte_eventdev_ops {
> > eventdev_timer_adapter_caps_get_t timer_adapter_caps_get;
> > /**< Get timer adapter capabilities */
> >
> > + eventdev_crypto_adapter_caps_get_t crypto_adapter_caps_get;
> > + /**< Get crypto adapter capabilities */
> > + eventdev_crypto_adapter_queue_pair_add_t
> crypto_adapter_queue_pair_add;
> > + /**< Add queue pair to crypto adapter */
> > + eventdev_crypto_adapter_queue_pair_del_t
> crypto_adapter_queue_pair_del;
> > + /**< Delete queue pair from crypto adapter */
> > + eventdev_crypto_adapter_start_t crypto_adapter_start;
> > + /**< Start crypto adapter */
> > + eventdev_crypto_adapter_stop_t crypto_adapter_stop;
> > + /**< Stop crypto adapter */
> > + eventdev_crypto_adapter_stats_get crypto_adapter_stats_get;
> > + /**< Get crypto stats */
> > + eventdev_crypto_adapter_stats_reset crypto_adapter_stats_reset;
> > + /**< Reset crypto stats */
> > +
> > eventdev_selftest dev_selftest;
> > /**< Start eventdev Selftest */
> >
> > --
> > 1.9.1
> >
^ permalink raw reply [flat|nested] 29+ messages in thread
* [dpdk-dev] [v2,3/6] eventdev: add crypto adapter implementation
2018-04-24 12:43 [dpdk-dev] [v2,0/6] eventdev: cover letter - crypto adapter Abhinandan Gujjar
2018-04-24 12:43 ` [dpdk-dev] [v2,1/6] eventdev: introduce event " Abhinandan Gujjar
2018-04-24 12:43 ` [dpdk-dev] [v2, 2/6] eventdev: add APIs and PMD callbacks for " Abhinandan Gujjar
@ 2018-04-24 12:43 ` Abhinandan Gujjar
2018-04-25 14:14 ` [dpdk-dev] [v2, 3/6] " Akhil Goyal
2018-04-29 16:22 ` Jerin Jacob
2018-04-24 12:43 ` [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test Abhinandan Gujjar
` (2 subsequent siblings)
5 siblings, 2 replies; 29+ messages in thread
From: Abhinandan Gujjar @ 2018-04-24 12:43 UTC (permalink / raw)
To: jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, abhinandan.gujjar, nikhil.rao, gage.eads
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
config/common_base | 1 +
lib/Makefile | 4 +-
lib/librte_eventdev/Makefile | 3 +
lib/librte_eventdev/rte_event_crypto_adapter.c | 1116 ++++++++++++++++++++++++
lib/librte_eventdev/rte_eventdev_version.map | 12 +
5 files changed, 1135 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_eventdev/rte_event_crypto_adapter.c
diff --git a/config/common_base b/config/common_base
index 0e82935..d10b9c2 100644
--- a/config/common_base
+++ b/config/common_base
@@ -558,6 +558,7 @@ CONFIG_RTE_LIBRTE_EVENTDEV_DEBUG=n
CONFIG_RTE_EVENT_MAX_DEVS=16
CONFIG_RTE_EVENT_MAX_QUEUES_PER_DEV=64
CONFIG_RTE_EVENT_TIMER_ADAPTER_NUM_MAX=32
+CONFIG_RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE=32
#
# Compile PMD for skeleton event device
diff --git a/lib/Makefile b/lib/Makefile
index 965be6c..0316025 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -31,7 +31,9 @@ DEPDIRS-librte_security := librte_eal librte_mempool librte_ring librte_mbuf
DEPDIRS-librte_security += librte_ether
DEPDIRS-librte_security += librte_cryptodev
DIRS-$(CONFIG_RTE_LIBRTE_EVENTDEV) += librte_eventdev
-DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ether librte_hash librte_mempool librte_timer
+DEPDIRS-librte_eventdev := librte_eal librte_ring librte_ether librte_hash \
+ librte_mempool librte_timer librte_cryptodev
+
DIRS-$(CONFIG_RTE_LIBRTE_RAWDEV) += librte_rawdev
DEPDIRS-librte_rawdev := librte_eal librte_ether
DIRS-$(CONFIG_RTE_LIBRTE_VHOST) += librte_vhost
diff --git a/lib/librte_eventdev/Makefile b/lib/librte_eventdev/Makefile
index 297df4a..804b036 100644
--- a/lib/librte_eventdev/Makefile
+++ b/lib/librte_eventdev/Makefile
@@ -15,12 +15,14 @@ CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
LDLIBS += -lrte_eal -lrte_ring -lrte_ethdev -lrte_hash -lrte_mempool -lrte_timer
+LDLIBS += -lrte_cryptodev -lrte_mempool
# library source files
SRCS-y += rte_eventdev.c
SRCS-y += rte_event_ring.c
SRCS-y += rte_event_eth_rx_adapter.c
SRCS-y += rte_event_timer_adapter.c
+SRCS-y += rte_event_crypto_adapter.c
# export include files
SYMLINK-y-include += rte_eventdev.h
@@ -31,6 +33,7 @@ SYMLINK-y-include += rte_event_ring.h
SYMLINK-y-include += rte_event_eth_rx_adapter.h
SYMLINK-y-include += rte_event_timer_adapter.h
SYMLINK-y-include += rte_event_timer_adapter_pmd.h
+SYMLINK-y-include += rte_event_crypto_adapter.h
# versioning export map
EXPORT_MAP := rte_eventdev_version.map
diff --git a/lib/librte_eventdev/rte_event_crypto_adapter.c b/lib/librte_eventdev/rte_event_crypto_adapter.c
new file mode 100644
index 0000000..a7dde71
--- /dev/null
+++ b/lib/librte_eventdev/rte_event_crypto_adapter.c
@@ -0,0 +1,1116 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2017-2018 Intel Corporation
+ */
+
+#include <string.h>
+#include <stdbool.h>
+#include <rte_common.h>
+#include <rte_dev.h>
+#include <rte_errno.h>
+#include <rte_cryptodev.h>
+#include <rte_cryptodev_pmd.h>
+#include <rte_log.h>
+#include <rte_malloc.h>
+#include <rte_service_component.h>
+
+#include "rte_eventdev.h"
+#include "rte_eventdev_pmd.h"
+#include "rte_event_crypto_adapter.h"
+
+#define BATCH_SIZE 32
+#define DEFAULT_MAX_NB 128
+#define CRYPTO_ADAPTER_NAME_LEN 32
+#define CRYPTO_ADAPTER_MEM_NAME_LEN 32
+#define CRYPTO_ADAPTER_MAX_EV_ENQ_RETRIES 100
+
+/* Flush an instance's enqueue buffers every CRYPTO_ENQ_FLUSH_THRESHOLD
+ * iterations of eca_crypto_adapter_enq_run()
+ */
+#define CRYPTO_ENQ_FLUSH_THRESHOLD 1024
+
+struct rte_event_crypto_adapter {
+ /* Event device identifier */
+ uint8_t eventdev_id;
+ /* Event port identifier */
+ uint8_t event_port_id;
+ /* Store event device's implicit release capability */
+ uint8_t implicit_release_disabled;
+ /* Max crypto ops processed in any service function invocation */
+ uint32_t max_nb;
+ /* Lock to serialize config updates with service function */
+ rte_spinlock_t lock;
+ /* Next crypto device to be processed */
+ uint16_t next_cdev_id;
+ /* Per crypto device structure */
+ struct crypto_device_info *cdevs;
+ /* Loop counter to flush crypto ops */
+ uint16_t transmit_loop_count;
+ /* Per instance stats structure */
+ struct rte_event_crypto_adapter_stats crypto_stats;
+ /* Configuration callback for rte_service configuration */
+ rte_event_crypto_adapter_conf_cb conf_cb;
+ /* Configuration callback argument */
+ void *conf_arg;
+ /* Set if default_cb is being used */
+ int default_cb_arg;
+ /* Service initialization state */
+ uint8_t service_inited;
+ /* Memory allocation name */
+ char mem_name[CRYPTO_ADAPTER_MEM_NAME_LEN];
+ /* Socket identifier cached from eventdev */
+ int socket_id;
+ /* Per adapter EAL service */
+ uint32_t service_id;
+ /* No. of queue pairs configured */
+ uint16_t nb_qps;
+ /* Adapter mode */
+ enum rte_event_crypto_adapter_mode mode;
+} __rte_cache_aligned;
+
+/* Per crypto device information */
+struct crypto_device_info {
+ /* Pointer to cryptodev */
+ struct rte_cryptodev *dev;
+ /* Pointer to queue pair info */
+ struct crypto_queue_pair_info *qpairs;
+ /* Next queue pair to be processed */
+ uint16_t next_queue_pair_id;
+ /* Set to indicate cryptodev->eventdev packet
+ * transfer uses a hardware mechanism
+ */
+ uint8_t internal_event_port;
+ /* Set to indicate processing has been started */
+ uint8_t dev_started;
+ /* If num_qpairs > 0, the start callback will
+ * be invoked if not already invoked
+ */
+ uint16_t num_qpairs;
+};
+
+/* Per queue pair information */
+struct crypto_queue_pair_info {
+ /* Set to indicate queue pair is enabled */
+ bool qp_enabled;
+ /* Pointer to hold rte_crypto_ops for batching */
+ struct rte_crypto_op **op_buffer;
+ /* No of crypto ops accumulated */
+ uint8_t len;
+};
+
+static struct rte_event_crypto_adapter **event_crypto_adapter;
+
+/* Macros to check for valid adapter */
+#define RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, retval) do { \
+ if (!eca_valid_id(id)) { \
+ RTE_EDEV_LOG_ERR("Invalid crypto adapter id = %d\n", id); \
+ return retval; \
+ } \
+} while (0)
+
+static inline int
+eca_valid_id(uint8_t id)
+{
+ return id < RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE;
+}
+
+static int
+eca_init(void)
+{
+ const char *name = "crypto_adapter_array";
+ const struct rte_memzone *mz;
+ unsigned int sz;
+
+ sz = sizeof(*event_crypto_adapter) *
+ RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE;
+ sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
+
+ mz = rte_memzone_lookup(name);
+ if (mz == NULL) {
+ mz = rte_memzone_reserve_aligned(name, sz, rte_socket_id(), 0,
+ RTE_CACHE_LINE_SIZE);
+ if (mz == NULL) {
+ RTE_EDEV_LOG_ERR("failed to reserve memzone err = %"
+ PRId32, rte_errno);
+ return -rte_errno;
+ }
+ }
+
+ event_crypto_adapter = mz->addr;
+ return 0;
+}
+
+static inline struct rte_event_crypto_adapter *
+eca_id_to_adapter(uint8_t id)
+{
+ return event_crypto_adapter ?
+ event_crypto_adapter[id] : NULL;
+}
+
+static int
+eca_default_config_cb(uint8_t id, uint8_t dev_id,
+ struct rte_event_crypto_adapter_conf *conf, void *arg)
+{
+ struct rte_event_dev_config dev_conf;
+ struct rte_eventdev *dev;
+ uint8_t port_id;
+ int started;
+ int ret;
+ struct rte_event_port_conf *port_conf = arg;
+ struct rte_event_crypto_adapter *adapter = eca_id_to_adapter(id);
+
+ dev = &rte_eventdevs[adapter->eventdev_id];
+ dev_conf = dev->data->dev_conf;
+
+ started = dev->data->dev_started;
+ if (started)
+ rte_event_dev_stop(dev_id);
+ port_id = dev_conf.nb_event_ports;
+ dev_conf.nb_event_ports += 1;
+ ret = rte_event_dev_configure(dev_id, &dev_conf);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("failed to configure event dev %u\n", dev_id);
+ if (started) {
+ if (rte_event_dev_start(dev_id))
+ return -EIO;
+ }
+ return ret;
+ }
+
+ ret = rte_event_port_setup(dev_id, port_id, port_conf);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("failed to setup event port %u\n", port_id);
+ return ret;
+ }
+
+ conf->event_port_id = port_id;
+ conf->max_nb = DEFAULT_MAX_NB;
+ if (started)
+ ret = rte_event_dev_start(dev_id);
+
+ adapter->default_cb_arg = 1;
+ return ret;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_create_ext(uint8_t id, uint8_t dev_id,
+ rte_event_crypto_adapter_conf_cb conf_cb,
+ enum rte_event_crypto_adapter_mode mode,
+ void *conf_arg)
+{
+ struct rte_event_crypto_adapter *adapter;
+ char mem_name[CRYPTO_ADAPTER_NAME_LEN];
+ struct rte_event_dev_info dev_info;
+ int socket_id;
+ uint8_t i;
+ int ret;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+ RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+ if (conf_cb == NULL)
+ return -EINVAL;
+
+ if (event_crypto_adapter == NULL) {
+ ret = eca_init();
+ if (ret)
+ return ret;
+ }
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter != NULL) {
+ RTE_EDEV_LOG_ERR("Crypto adapter id %u already exists!", id);
+ return -EEXIST;
+ }
+
+ socket_id = rte_event_dev_socket_id(dev_id);
+ snprintf(mem_name, CRYPTO_ADAPTER_MEM_NAME_LEN,
+ "rte_event_crypto_adapter_%d", id);
+
+ adapter = rte_zmalloc_socket(mem_name, sizeof(*adapter),
+ RTE_CACHE_LINE_SIZE, socket_id);
+ if (adapter == NULL) {
+ RTE_EDEV_LOG_ERR("Failed to get mem for event crypto adapter!");
+ return -ENOMEM;
+ }
+
+ ret = rte_event_dev_info_get(dev_id, &dev_info);
+ if (ret < 0) {
+ RTE_EDEV_LOG_ERR("Failed to get info for eventdev %d: %s!",
+ dev_id, dev_info.driver_name);
+ return ret;
+ }
+
+ adapter->implicit_release_disabled = (dev_info.event_dev_cap &
+ RTE_EVENT_DEV_CAP_IMPLICIT_RELEASE_DISABLE);
+ adapter->eventdev_id = dev_id;
+ adapter->socket_id = socket_id;
+ adapter->conf_cb = conf_cb;
+ adapter->conf_arg = conf_arg;
+ adapter->mode = mode;
+ strcpy(adapter->mem_name, mem_name);
+ adapter->cdevs = rte_zmalloc_socket(adapter->mem_name,
+ rte_cryptodev_count() *
+ sizeof(struct crypto_device_info), 0,
+ socket_id);
+ if (adapter->cdevs == NULL) {
+ RTE_EDEV_LOG_ERR("Failed to get mem for crypto devices\n");
+ rte_free(adapter);
+ return -ENOMEM;
+ }
+
+ rte_spinlock_init(&adapter->lock);
+ for (i = 0; i < rte_cryptodev_count(); i++)
+ adapter->cdevs[i].dev = rte_cryptodev_pmd_get_dev(i);
+
+ event_crypto_adapter[id] = adapter;
+
+ return 0;
+}
+
+
+int __rte_experimental
+rte_event_crypto_adapter_create(uint8_t id, uint8_t dev_id,
+ struct rte_event_port_conf *port_config,
+ enum rte_event_crypto_adapter_mode mode)
+{
+ struct rte_event_port_conf *pc;
+ int ret;
+
+ if (port_config == NULL)
+ return -EINVAL;
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ pc = rte_malloc(NULL, sizeof(*pc), 0);
+ if (pc == NULL)
+ return -ENOMEM;
+ *pc = *port_config;
+ ret = rte_event_crypto_adapter_create_ext(id, dev_id,
+ eca_default_config_cb,
+ mode,
+ pc);
+ if (ret)
+ rte_free(pc);
+
+ return ret;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_free(uint8_t id)
+{
+ struct rte_event_crypto_adapter *adapter;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL)
+ return -EINVAL;
+
+ if (adapter->nb_qps) {
+ RTE_EDEV_LOG_ERR("%" PRIu16 "Queue pairs not deleted",
+ adapter->nb_qps);
+ return -EBUSY;
+ }
+
+ if (adapter->default_cb_arg)
+ rte_free(adapter->conf_arg);
+ rte_free(adapter->cdevs);
+ rte_free(adapter);
+ event_crypto_adapter[id] = NULL;
+
+ return 0;
+}
+
+static inline unsigned int
+eca_enq_to_cryptodev(struct rte_event_crypto_adapter *adapter,
+ struct rte_event *ev, unsigned int cnt)
+{
+ struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
+ union rte_event_crypto_metadata *m_data = NULL;
+ struct crypto_queue_pair_info *qp_info = NULL;
+ struct rte_crypto_op *crypto_op;
+ unsigned int i, n = 0;
+ uint16_t qp_id = 0, len = 0, ret = 0;
+ uint8_t cdev_id = 0;
+
+ stats->event_dequeue_count += cnt;
+
+ for (i = 0; i < cnt; i++) {
+ 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_private_data(
+ crypto_op->sym->session);
+ 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 == NULL) {
+ rte_pktmbuf_free(crypto_op->sym->m_src);
+ rte_crypto_op_free(crypto_op);
+ continue;
+ }
+ len = qp_info->len;
+ qp_info->op_buffer[len] = crypto_op;
+ len++;
+ } 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 == NULL) {
+ rte_pktmbuf_free(crypto_op->sym->m_src);
+ rte_crypto_op_free(crypto_op);
+ continue;
+ }
+ len = qp_info->len;
+ qp_info->op_buffer[len] = crypto_op;
+ len++;
+ } else {
+ rte_pktmbuf_free(crypto_op->sym->m_src);
+ rte_crypto_op_free(crypto_op);
+ continue;
+ }
+
+ if (len == BATCH_SIZE) {
+ struct rte_crypto_op **op_buffer = qp_info->op_buffer;
+ ret = rte_cryptodev_enqueue_burst(cdev_id,
+ qp_id,
+ op_buffer,
+ BATCH_SIZE);
+
+ stats->crypto_enq_count += ret;
+
+ while (ret < len) {
+ struct rte_crypto_op *op;
+ op = op_buffer[ret++];
+ stats->crypto_enq_fail++;
+ rte_pktmbuf_free(op->sym->m_src);
+ rte_crypto_op_free(op);
+ }
+
+ len = 0;
+ }
+
+ if (qp_info)
+ qp_info->len = len;
+ n += ret;
+ }
+
+ return n;
+}
+
+static unsigned int
+eca_crypto_enq_flush(struct rte_event_crypto_adapter *adapter)
+{
+ struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
+ struct crypto_device_info *curr_dev;
+ struct crypto_queue_pair_info *curr_queue;
+ struct rte_crypto_op **op_buffer;
+ struct rte_cryptodev *dev;
+ uint8_t cdev_id;
+ uint16_t qp;
+ uint16_t ret = 0;
+ uint16_t num_cdev = rte_cryptodev_count();
+
+ for (cdev_id = 0; cdev_id < num_cdev; cdev_id++) {
+ curr_dev = &adapter->cdevs[cdev_id];
+ if (curr_dev == NULL)
+ continue;
+ dev = curr_dev->dev;
+
+ for (qp = 0; qp < dev->data->nb_queue_pairs; qp++) {
+
+ curr_queue = &curr_dev->qpairs[qp];
+ if (!curr_queue->qp_enabled)
+ continue;
+
+ op_buffer = curr_queue->op_buffer;
+ ret = rte_cryptodev_enqueue_burst(cdev_id,
+ qp,
+ op_buffer,
+ curr_queue->len);
+ stats->crypto_enq_count += ret;
+
+ while (ret < curr_queue->len) {
+ struct rte_crypto_op *op;
+ op = op_buffer[ret++];
+ stats->crypto_enq_fail++;
+ rte_pktmbuf_free(op->sym->m_src);
+ rte_crypto_op_free(op);
+ }
+ curr_queue->len = 0;
+ }
+ }
+
+ return ret;
+}
+
+static int
+eca_crypto_adapter_enq_run(struct rte_event_crypto_adapter *adapter,
+ unsigned int max_enq)
+{
+ struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
+ struct rte_event ev[BATCH_SIZE];
+ unsigned int nb_enq, nb_enqueued = 0;
+ uint16_t n;
+ uint8_t event_dev_id = adapter->eventdev_id;
+ uint8_t event_port_id = adapter->event_port_id;
+
+
+ if (adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY)
+ return 0;
+
+ for (nb_enq = 0; nb_enq < max_enq; nb_enq += n) {
+ stats->event_poll_count++;
+ n = rte_event_dequeue_burst(event_dev_id,
+ event_port_id, ev, BATCH_SIZE, 0);
+
+ if (!n)
+ break;
+
+ nb_enqueued += eca_enq_to_cryptodev(adapter, ev, n);
+ }
+
+ if ((++adapter->transmit_loop_count &
+ (CRYPTO_ENQ_FLUSH_THRESHOLD - 1)) == 0) {
+ nb_enqueued += eca_crypto_enq_flush(adapter);
+ }
+
+ return nb_enqueued;
+}
+
+static inline void
+eca_ops_enqueue_burst(struct rte_event_crypto_adapter *adapter,
+ struct rte_crypto_op **ops, uint16_t num)
+{
+ struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
+ union rte_event_crypto_metadata *m_data = NULL;
+ uint8_t event_dev_id = adapter->eventdev_id;
+ uint8_t event_port_id = adapter->event_port_id;
+ struct rte_event events[BATCH_SIZE];
+ uint16_t nb_enqueued = 0, nb_ev = 0;
+ uint8_t retry = 0;
+ uint8_t i;
+
+ num = RTE_MIN(num, BATCH_SIZE);
+ for (i = 0; i < num; i++) {
+ struct rte_event *ev = &events[nb_ev++];
+ if (ops[i]->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
+ m_data = rte_cryptodev_sym_session_get_private_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);
+ }
+
+ if (unlikely(m_data == NULL)) {
+ rte_pktmbuf_free(ops[i]->sym->m_src);
+ rte_crypto_op_free(ops[i]);
+ continue;
+ }
+
+ rte_memcpy(ev, &m_data->response_info, sizeof(ev));
+ ev->event_ptr = ops[i];
+ ev->event_type = RTE_EVENT_TYPE_CRYPTODEV;
+ if (adapter->implicit_release_disabled)
+ ev->op = RTE_EVENT_OP_FORWARD;
+ else
+ ev->op = RTE_EVENT_OP_NEW;
+ }
+
+ do {
+ nb_enqueued += rte_event_enqueue_burst(event_dev_id,
+ event_port_id,
+ &events[nb_enqueued],
+ nb_ev - nb_enqueued);
+ } while (retry++ < CRYPTO_ADAPTER_MAX_EV_ENQ_RETRIES &&
+ nb_enqueued < nb_ev);
+
+ /* Free mbufs and rte_crypto_ops for failed events */
+ for (i = nb_enqueued; i < nb_ev; i++) {
+ struct rte_crypto_op *op = events[i].event_ptr;
+ rte_pktmbuf_free(op->sym->m_src);
+ rte_crypto_op_free(op);
+ }
+
+ stats->event_enq_fail_count += nb_ev - nb_enqueued;
+ stats->event_enqueue_count += nb_enqueued;
+ stats->event_enq_retry_count += retry - 1;
+}
+
+static inline unsigned int
+eca_crypto_adapter_deq_run(struct rte_event_crypto_adapter *adapter,
+ unsigned int max_deq)
+{
+ struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
+ struct crypto_device_info *curr_dev;
+ struct crypto_queue_pair_info *curr_queue;
+ struct rte_crypto_op *ops[BATCH_SIZE];
+ uint16_t n, nb_deq;
+ struct rte_cryptodev *dev;
+ uint8_t cdev_id;
+ uint16_t qp, dev_qps;
+ bool done;
+ uint16_t num_cdev = rte_cryptodev_count();
+
+ nb_deq = 0;
+ do {
+ uint16_t queues = 0;
+ done = true;
+
+ for (cdev_id = adapter->next_cdev_id;
+ cdev_id < num_cdev; cdev_id++) {
+ curr_dev = &adapter->cdevs[cdev_id];
+ if (curr_dev == NULL)
+ continue;
+ dev = curr_dev->dev;
+ dev_qps = dev->data->nb_queue_pairs;
+
+ for (qp = curr_dev->next_queue_pair_id;
+ queues < dev_qps; qp = (qp + 1) % dev_qps,
+ queues++) {
+
+ curr_queue = &curr_dev->qpairs[qp];
+ if (!curr_queue->qp_enabled)
+ continue;
+
+ n = rte_cryptodev_dequeue_burst(cdev_id, qp,
+ ops, BATCH_SIZE);
+ if (!n)
+ continue;
+
+ done = false;
+ stats->crypto_deq_count += n;
+ eca_ops_enqueue_burst(adapter, ops, n);
+ nb_deq += n;
+
+ if (nb_deq > max_deq) {
+ if ((qp + 1) == dev_qps) {
+ adapter->next_cdev_id =
+ (cdev_id + 1)
+ % num_cdev;
+ }
+ curr_dev->next_queue_pair_id = (qp + 1)
+ % dev->data->nb_queue_pairs;
+
+ return nb_deq;
+ }
+ }
+ }
+ } while (done == false);
+ return nb_deq;
+}
+
+static void
+eca_crypto_adapter_run(struct rte_event_crypto_adapter *adapter,
+ unsigned int max_ops)
+{
+ while (max_ops) {
+ unsigned int e_cnt, d_cnt;
+
+ e_cnt = eca_crypto_adapter_deq_run(adapter, max_ops);
+ max_ops -= RTE_MIN(max_ops, e_cnt);
+
+ d_cnt = eca_crypto_adapter_enq_run(adapter, max_ops);
+ max_ops -= RTE_MIN(max_ops, d_cnt);
+
+ if (e_cnt == 0 && d_cnt == 0)
+ break;
+
+ }
+}
+
+static int
+eca_service_func(void *args)
+{
+ struct rte_event_crypto_adapter *adapter = args;
+
+ if (rte_spinlock_trylock(&adapter->lock) == 0)
+ return 0;
+ eca_crypto_adapter_run(adapter, adapter->max_nb);
+ rte_spinlock_unlock(&adapter->lock);
+
+ return 0;
+}
+
+static int
+eca_init_service(struct rte_event_crypto_adapter *adapter, uint8_t id)
+{
+ struct rte_event_crypto_adapter_conf adapter_conf;
+ struct rte_service_spec service;
+ int ret;
+
+ if (adapter->service_inited)
+ return 0;
+
+ memset(&service, 0, sizeof(service));
+ snprintf(service.name, CRYPTO_ADAPTER_NAME_LEN,
+ "rte_event_crypto_adapter_%d", id);
+ service.socket_id = adapter->socket_id;
+ service.callback = eca_service_func;
+ service.callback_userdata = adapter;
+ /* Service function handles locking for queue add/del updates */
+ service.capabilities = RTE_SERVICE_CAP_MT_SAFE;
+ ret = rte_service_component_register(&service, &adapter->service_id);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("failed to register service %s err = %" PRId32,
+ service.name, ret);
+ return ret;
+ }
+
+ ret = adapter->conf_cb(id, adapter->eventdev_id,
+ &adapter_conf, adapter->conf_arg);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("configuration callback failed err = %" PRId32,
+ ret);
+ return ret;
+ }
+
+ adapter->max_nb = adapter_conf.max_nb;
+ adapter->event_port_id = adapter_conf.event_port_id;
+ adapter->service_inited = 1;
+
+ return ret;
+}
+
+static void
+eca_update_qp_info(struct rte_event_crypto_adapter *adapter,
+ struct crypto_device_info *dev_info,
+ int32_t queue_pair_id,
+ uint8_t add)
+{
+ struct crypto_queue_pair_info *qp_info;
+ int enabled;
+ uint16_t i;
+
+ if (dev_info->qpairs == NULL)
+ return;
+
+ if (queue_pair_id == -1) {
+ for (i = 0; i < dev_info->dev->data->nb_queue_pairs; i++)
+ eca_update_qp_info(adapter, dev_info, i, add);
+ } else {
+ qp_info = &dev_info->qpairs[queue_pair_id];
+ enabled = qp_info->qp_enabled;
+ if (add) {
+ adapter->nb_qps += !enabled;
+ dev_info->num_qpairs += !enabled;
+ } else {
+ adapter->nb_qps -= enabled;
+ dev_info->num_qpairs -= enabled;
+ }
+ qp_info->qp_enabled = !!add;
+ }
+}
+
+static int
+eca_add_queue_pair(struct rte_event_crypto_adapter *adapter,
+ uint8_t cdev_id,
+ int queue_pair_id)
+{
+ struct crypto_device_info *dev_info = &adapter->cdevs[cdev_id];
+ struct crypto_queue_pair_info *qpairs;
+ uint32_t i;
+
+ if (dev_info->qpairs == NULL) {
+ dev_info->qpairs =
+ rte_zmalloc_socket(adapter->mem_name,
+ dev_info->dev->data->nb_queue_pairs *
+ sizeof(struct crypto_queue_pair_info),
+ 0, adapter->socket_id);
+ if (dev_info->qpairs == NULL)
+ return -ENOMEM;
+
+ qpairs = dev_info->qpairs;
+ qpairs->op_buffer = rte_zmalloc_socket(adapter->mem_name,
+ BATCH_SIZE *
+ sizeof(struct rte_crypto_op *),
+ 0, adapter->socket_id);
+ if (!qpairs->op_buffer) {
+ rte_free(qpairs);
+ return -ENOMEM;
+ }
+ }
+
+ if (queue_pair_id == -1) {
+ for (i = 0; i < dev_info->dev->data->nb_queue_pairs; i++)
+ eca_update_qp_info(adapter, dev_info, i, 1);
+ } else
+ eca_update_qp_info(adapter, dev_info,
+ (uint16_t)queue_pair_id, 1);
+
+ return 0;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_queue_pair_add(uint8_t id,
+ uint8_t cdev_id,
+ int32_t queue_pair_id,
+ const struct rte_event_crypto_queue_pair_conf *conf)
+{
+ struct rte_event_crypto_adapter *adapter;
+ struct rte_eventdev *dev;
+ struct crypto_device_info *dev_info;
+ uint32_t cap;
+ int ret;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) {
+ RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id);
+ return -EINVAL;
+ }
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL)
+ return -EINVAL;
+
+ dev = &rte_eventdevs[adapter->eventdev_id];
+ ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id,
+ cdev_id,
+ &cap);
+ if (ret) {
+ RTE_EDEV_LOG_ERR("Failed to get adapter caps dev %" PRIu8
+ " cdev %" PRIu8, id, cdev_id);
+ return ret;
+ }
+
+ if ((cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND) &&
+ (conf == NULL)) {
+ RTE_EDEV_LOG_ERR("Conf value can not be NULL for dev_id=%u",
+ cdev_id);
+ return -EINVAL;
+ }
+
+ dev_info = &adapter->cdevs[cdev_id];
+
+ if (queue_pair_id != -1 &&
+ (uint16_t)queue_pair_id >= dev_info->dev->data->nb_queue_pairs) {
+ RTE_EDEV_LOG_ERR("Invalid queue_pair_id %" PRIu16,
+ (uint16_t)queue_pair_id);
+ return -EINVAL;
+ }
+
+ /* In case HW cap is RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD,
+ * no need of service core as HW takes care of enqueuing events to
+ * event device.
+ */
+ if ((cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) ||
+ (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
+ adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY)) {
+ RTE_FUNC_PTR_OR_ERR_RET(
+ *dev->dev_ops->crypto_adapter_queue_pair_add,
+ -ENOTSUP);
+ if (dev_info->qpairs == NULL) {
+ dev_info->qpairs =
+ rte_zmalloc_socket(adapter->mem_name,
+ dev_info->dev->data->nb_queue_pairs *
+ sizeof(struct crypto_queue_pair_info),
+ 0, adapter->socket_id);
+ if (dev_info->qpairs == NULL)
+ return -ENOMEM;
+ }
+
+ ret = (*dev->dev_ops->crypto_adapter_queue_pair_add)(dev,
+ dev_info->dev,
+ queue_pair_id,
+ conf);
+ if (ret == 0) {
+ eca_update_qp_info(adapter,
+ &adapter->cdevs[cdev_id],
+ queue_pair_id,
+ 1);
+ }
+
+ return 0;
+ }
+
+ /* In case HW cap is RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW,
+ * or SW adapter, initiate services so the application can choose
+ * which ever way it wants to use the adapter.
+ * Case 1: RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW
+ * Application may wants to use one of below two mode
+ * a. ENQ-DEQ mode -> HW Dequeue + SW enqueue
+ * b. DEQ-ONLY mode -> HW Dequeue
+ * Case 2: No HW caps, use SW adapter
+ * a. ENQ-DEQ mode -> SW enqueue & dequeue
+ * b. DEQ-ONLY mode -> SW Dequeue
+ */
+ if ((cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
+ adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ) || cap) {
+ rte_spinlock_lock(&adapter->lock);
+ ret = eca_init_service(adapter, id);
+ if (ret == 0)
+ ret = eca_add_queue_pair(adapter, cdev_id,
+ queue_pair_id);
+ rte_spinlock_unlock(&adapter->lock);
+ }
+
+ if (ret)
+ return ret;
+
+ rte_service_component_runstate_set(adapter->service_id, 1);
+
+ return 0;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_queue_pair_del(uint8_t id, uint8_t cdev_id,
+ int32_t queue_pair_id)
+{
+ struct rte_event_crypto_adapter *adapter;
+ struct crypto_device_info *dev_info;
+ struct rte_eventdev *dev;
+ int ret = 0;
+ uint32_t cap;
+ uint16_t i;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) {
+ RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id);
+ return -EINVAL;
+ }
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL)
+ return -EINVAL;
+
+ dev = &rte_eventdevs[adapter->eventdev_id];
+ ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id,
+ cdev_id,
+ &cap);
+ if (ret)
+ return ret;
+
+ dev_info = &adapter->cdevs[cdev_id];
+
+ if (queue_pair_id != -1 &&
+ (uint16_t)queue_pair_id >= dev_info->dev->data->nb_queue_pairs) {
+ RTE_EDEV_LOG_ERR("Invalid queue_pair_id %" PRIu16,
+ (uint16_t)queue_pair_id);
+ return -EINVAL;
+ }
+
+ if ((cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) ||
+ (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
+ adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY)) {
+ RTE_FUNC_PTR_OR_ERR_RET(
+ *dev->dev_ops->crypto_adapter_queue_pair_del,
+ -ENOTSUP);
+ ret = (*dev->dev_ops->crypto_adapter_queue_pair_del)(dev,
+ dev_info->dev,
+ queue_pair_id);
+ if (ret == 0) {
+ eca_update_qp_info(adapter,
+ &adapter->cdevs[cdev_id],
+ queue_pair_id,
+ 0);
+ if (dev_info->num_qpairs == 0) {
+ rte_free(dev_info->qpairs);
+ dev_info->qpairs = NULL;
+ }
+ }
+ } else {
+ if (adapter->nb_qps == 0)
+ return 0;
+
+ rte_spinlock_lock(&adapter->lock);
+ if (queue_pair_id == -1) {
+ for (i = 0; i < dev_info->dev->data->nb_queue_pairs;
+ i++)
+ eca_update_qp_info(adapter, dev_info,
+ queue_pair_id, 0);
+ } else {
+ eca_update_qp_info(adapter, dev_info,
+ (uint16_t)queue_pair_id, 0);
+ }
+
+ if (dev_info->num_qpairs == 0) {
+ rte_free(dev_info->qpairs);
+ dev_info->qpairs = NULL;
+ }
+
+ rte_spinlock_unlock(&adapter->lock);
+ rte_service_component_runstate_set(adapter->service_id,
+ adapter->nb_qps);
+ }
+
+ return ret;
+}
+
+static int
+eca_adapter_ctrl(uint8_t id, int start)
+{
+ struct rte_event_crypto_adapter *adapter;
+ struct crypto_device_info *dev_info;
+ struct rte_eventdev *dev;
+ uint32_t i;
+ int use_service = 0;
+ int stop = !start;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL)
+ return -EINVAL;
+
+ dev = &rte_eventdevs[adapter->eventdev_id];
+
+ for (i = 0; i < rte_cryptodev_count(); i++) {
+ dev_info = &adapter->cdevs[i];
+ /* if start check for num queue pairs */
+ if (start && !dev_info->num_qpairs)
+ continue;
+ /* if stop check if dev has been started */
+ if (stop && !dev_info->dev_started)
+ continue;
+ use_service |= !dev_info->internal_event_port;
+ dev_info->dev_started = start;
+ if (dev_info->internal_event_port == 0)
+ continue;
+ start ? (*dev->dev_ops->crypto_adapter_start)(dev,
+ &dev_info->dev[i]) :
+ (*dev->dev_ops->crypto_adapter_stop)(dev,
+ &dev_info->dev[i]);
+ }
+
+ if (use_service)
+ rte_service_runstate_set(adapter->service_id, start);
+
+ return 0;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_start(uint8_t id)
+{
+ struct rte_event_crypto_adapter *adapter;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL)
+ return -EINVAL;
+
+ return eca_adapter_ctrl(id, 1);
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_stop(uint8_t id)
+{
+ return eca_adapter_ctrl(id, 0);
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_stats_get(uint8_t id,
+ struct rte_event_crypto_adapter_stats *stats)
+{
+ struct rte_event_crypto_adapter *adapter;
+ struct rte_event_crypto_adapter_stats dev_stats_sum = { 0 };
+ struct rte_event_crypto_adapter_stats dev_stats;
+ struct rte_eventdev *dev;
+ struct crypto_device_info *dev_info;
+ uint32_t i;
+ int ret;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL || stats == NULL)
+ return -EINVAL;
+
+ dev = &rte_eventdevs[adapter->eventdev_id];
+ memset(stats, 0, sizeof(*stats));
+ for (i = 0; i < rte_cryptodev_count(); i++) {
+ dev_info = &adapter->cdevs[i];
+ if (dev_info->internal_event_port == 0 ||
+ dev->dev_ops->crypto_adapter_stats_get == NULL)
+ continue;
+ ret = (*dev->dev_ops->crypto_adapter_stats_get)(dev,
+ dev_info->dev,
+ &dev_stats);
+ if (ret)
+ continue;
+
+ dev_stats_sum.crypto_deq_count += dev_stats.crypto_deq_count;
+ dev_stats_sum.event_enqueue_count +=
+ dev_stats.event_enqueue_count;
+ }
+
+ if (adapter->service_inited)
+ *stats = adapter->crypto_stats;
+
+ stats->crypto_deq_count += dev_stats_sum.crypto_deq_count;
+ stats->event_enqueue_count += dev_stats_sum.event_enqueue_count;
+
+ return 0;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_stats_reset(uint8_t id)
+{
+ struct rte_event_crypto_adapter *adapter;
+ struct crypto_device_info *dev_info;
+ struct rte_eventdev *dev;
+ uint32_t i;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL)
+ return -EINVAL;
+
+ dev = &rte_eventdevs[adapter->eventdev_id];
+ for (i = 0; i < rte_cryptodev_count(); i++) {
+ dev_info = &adapter->cdevs[i];
+ if (dev_info->internal_event_port == 0 ||
+ dev->dev_ops->crypto_adapter_stats_reset == NULL)
+ continue;
+ (*dev->dev_ops->crypto_adapter_stats_reset)(dev,
+ dev_info->dev);
+ }
+
+ memset(&adapter->crypto_stats, 0, sizeof(adapter->crypto_stats));
+ return 0;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_service_id_get(uint8_t id, uint32_t *service_id)
+{
+ struct rte_event_crypto_adapter *adapter;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL || service_id == NULL)
+ return -EINVAL;
+
+ if (adapter->service_inited)
+ *service_id = adapter->service_id;
+
+ return adapter->service_inited ? 0 : -ESRCH;
+}
+
+int __rte_experimental
+rte_event_crypto_adapter_event_port_get(uint8_t id, uint8_t *event_port_id)
+{
+ struct rte_event_crypto_adapter *adapter;
+
+ RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
+
+ adapter = eca_id_to_adapter(id);
+ if (adapter == NULL || event_port_id == NULL)
+ return -EINVAL;
+
+ *event_port_id = adapter->event_port_id;
+
+ return 0;
+}
diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
index 3ee28f7..774f7c5 100644
--- a/lib/librte_eventdev/rte_eventdev_version.map
+++ b/lib/librte_eventdev/rte_eventdev_version.map
@@ -72,6 +72,18 @@ DPDK_18.02 {
global:
rte_event_dev_selftest;
+ rte_event_crypto_adapter_create_ext;
+ rte_event_crypto_adapter_create;
+ rte_event_crypto_adapter_free;
+ rte_event_crypto_adapter_queue_pair_add;
+ rte_event_crypto_adapter_queue_pair_del;
+ rte_event_crypto_adapter_start;
+ rte_event_crypto_adapter_stop;
+ rte_event_crypto_adapter_stats_get;
+ rte_event_crypto_adapter_stats_reset;
+ rte_event_crypto_adapter_service_id_get;
+ rte_event_crypto_adapter_event_port_get;
+
} DPDK_17.11;
DPDK_18.05 {
--
1.9.1
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 3/6] eventdev: add crypto adapter implementation
2018-04-24 12:43 ` [dpdk-dev] [v2,3/6] eventdev: add crypto adapter implementation Abhinandan Gujjar
@ 2018-04-25 14:14 ` Akhil Goyal
2018-04-26 6:20 ` Gujjar, Abhinandan S
2018-04-29 16:22 ` Jerin Jacob
1 sibling, 1 reply; 29+ messages in thread
From: Akhil Goyal @ 2018-04-25 14:14 UTC (permalink / raw)
To: Abhinandan Gujjar, jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, nikhil.rao, gage.eads
On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
[snip..]
> +int __rte_experimental
> +rte_event_crypto_adapter_start(uint8_t id)
> +{
> + struct rte_event_crypto_adapter *adapter;
> +
> + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> + adapter = eca_id_to_adapter(id);
> + if (adapter == NULL)
> + return -EINVAL;
This check is redundant here. you are null checking it again in
eca_adapter_ctrl
> +
> + return eca_adapter_ctrl(id, 1);
> +}
> +
> +int __rte_experimental
> +rte_event_crypto_adapter_stop(uint8_t id)
> +{
> + return eca_adapter_ctrl(id, 0);
> +}
> +
[snip..]
> diff --git a/lib/librte_eventdev/rte_eventdev_version.map b/lib/librte_eventdev/rte_eventdev_version.map
> index 3ee28f7..774f7c5 100644
> --- a/lib/librte_eventdev/rte_eventdev_version.map
> +++ b/lib/librte_eventdev/rte_eventdev_version.map
> @@ -72,6 +72,18 @@ DPDK_18.02 {
> global:
>
> rte_event_dev_selftest;
> + rte_event_crypto_adapter_create_ext;
> + rte_event_crypto_adapter_create;
> + rte_event_crypto_adapter_free;
> + rte_event_crypto_adapter_queue_pair_add;
> + rte_event_crypto_adapter_queue_pair_del;
> + rte_event_crypto_adapter_start;
> + rte_event_crypto_adapter_stop;
> + rte_event_crypto_adapter_stats_get;
> + rte_event_crypto_adapter_stats_reset;
> + rte_event_crypto_adapter_service_id_get;
> + rte_event_crypto_adapter_event_port_get;
> +
I believe these shall go in EXPERIMENTAL along with timer.
> } DPDK_17.11;
>
> DPDK_18.05 {
>
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 3/6] eventdev: add crypto adapter implementation
2018-04-25 14:14 ` [dpdk-dev] [v2, 3/6] " Akhil Goyal
@ 2018-04-26 6:20 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-26 6:20 UTC (permalink / raw)
To: Akhil Goyal, jerin.jacob, hemant.agrawal, dev
Cc: Vangati, Narender, Rao, Nikhil, Eads, Gage
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, April 25, 2018 7:44 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com;
> akhil.goyal@nxp.com; dev@dpdk.org
> Cc: Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>
> Subject: Re: [dpdk-dev] [v2,3/6] eventdev: add crypto adapter implementation
>
> On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
>
> [snip..]
> > +int __rte_experimental
> > +rte_event_crypto_adapter_start(uint8_t id) {
> > + struct rte_event_crypto_adapter *adapter;
> > +
> > + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> > + adapter = eca_id_to_adapter(id);
> > + if (adapter == NULL)
> > + return -EINVAL;
> This check is redundant here. you are null checking it again in eca_adapter_ctrl
Ok.
> > +
> > + return eca_adapter_ctrl(id, 1);
> > +}
> > +
> > +int __rte_experimental
> > +rte_event_crypto_adapter_stop(uint8_t id) {
> > + return eca_adapter_ctrl(id, 0);
> > +}
> > +
>
> [snip..]
> > diff --git a/lib/librte_eventdev/rte_eventdev_version.map
> > b/lib/librte_eventdev/rte_eventdev_version.map
> > index 3ee28f7..774f7c5 100644
> > --- a/lib/librte_eventdev/rte_eventdev_version.map
> > +++ b/lib/librte_eventdev/rte_eventdev_version.map
> > @@ -72,6 +72,18 @@ DPDK_18.02 {
> > global:
> >
> > rte_event_dev_selftest;
> > + rte_event_crypto_adapter_create_ext;
> > + rte_event_crypto_adapter_create;
> > + rte_event_crypto_adapter_free;
> > + rte_event_crypto_adapter_queue_pair_add;
> > + rte_event_crypto_adapter_queue_pair_del;
> > + rte_event_crypto_adapter_start;
> > + rte_event_crypto_adapter_stop;
> > + rte_event_crypto_adapter_stats_get;
> > + rte_event_crypto_adapter_stats_reset;
> > + rte_event_crypto_adapter_service_id_get;
> > + rte_event_crypto_adapter_event_port_get;
> > +
> I believe these shall go in EXPERIMENTAL along with timer.
Ok
> > } DPDK_17.11;
> >
> > DPDK_18.05 {
> >
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [dpdk-dev] [v2, 3/6] eventdev: add crypto adapter implementation
2018-04-24 12:43 ` [dpdk-dev] [v2,3/6] eventdev: add crypto adapter implementation Abhinandan Gujjar
2018-04-25 14:14 ` [dpdk-dev] [v2, 3/6] " Akhil Goyal
@ 2018-04-29 16:22 ` Jerin Jacob
2018-04-30 11:18 ` Gujjar, Abhinandan S
1 sibling, 1 reply; 29+ messages in thread
From: Jerin Jacob @ 2018-04-29 16:22 UTC (permalink / raw)
To: Abhinandan Gujjar
Cc: hemant.agrawal, akhil.goyal, dev, narender.vangati, nikhil.rao,
gage.eads
-----Original Message-----
> Date: Tue, 24 Apr 2018 18:13:24 +0530
> From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> akhil.goyal@nxp.com, dev@dpdk.org
> CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> nikhil.rao@intel.com, gage.eads@intel.com
> Subject: [v2,3/6] eventdev: add crypto adapter implementation
> X-Mailer: git-send-email 1.9.1
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> +
> +/* Per crypto device information */
> +struct crypto_device_info {
> + /* Pointer to cryptodev */
> + struct rte_cryptodev *dev;
> + /* Pointer to queue pair info */
> + struct crypto_queue_pair_info *qpairs;
> + /* Next queue pair to be processed */
> + uint16_t next_queue_pair_id;
> + /* Set to indicate cryptodev->eventdev packet
> + * transfer uses a hardware mechanism
> + */
> + uint8_t internal_event_port;
> + /* Set to indicate processing has been started */
> + uint8_t dev_started;
> + /* If num_qpairs > 0, the start callback will
> + * be invoked if not already invoked
> + */
> + uint16_t num_qpairs;
> +};
Looks like it is used in fastpath, if so add the cache alignment.
> +
> +/* Per queue pair information */
> +struct crypto_queue_pair_info {
> + /* Set to indicate queue pair is enabled */
> + bool qp_enabled;
> + /* Pointer to hold rte_crypto_ops for batching */
> + struct rte_crypto_op **op_buffer;
> + /* No of crypto ops accumulated */
> + uint8_t len;
> +};
> +
> +static struct rte_event_crypto_adapter **event_crypto_adapter;
> +
> +eca_enq_to_cryptodev(struct rte_event_crypto_adapter *adapter,
> + struct rte_event *ev, unsigned int cnt)
> +{
> + struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
> + union rte_event_crypto_metadata *m_data = NULL;
> + struct crypto_queue_pair_info *qp_info = NULL;
> + struct rte_crypto_op *crypto_op;
> + unsigned int i, n = 0;
> + uint16_t qp_id = 0, len = 0, ret = 0;
Please review the explicit '0' assignment.
> + uint8_t cdev_id = 0;
> +
> + stats->event_dequeue_count += cnt;
> +
> + for (i = 0; i < cnt; i++) {
> + 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_private_data(
> + crypto_op->sym->session);
> + 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 == NULL) {
> + rte_pktmbuf_free(crypto_op->sym->m_src);
> + rte_crypto_op_free(crypto_op);
> + continue;
> + }
> + len = qp_info->len;
> + qp_info->op_buffer[len] = crypto_op;
> + len++;
> +
> +int __rte_experimental
> +rte_event_crypto_adapter_queue_pair_add(uint8_t id,
> + uint8_t cdev_id,
> + int32_t queue_pair_id,
> + const struct rte_event_crypto_queue_pair_conf *conf)
> +{
> + struct rte_event_crypto_adapter *adapter;
> + struct rte_eventdev *dev;
> + struct crypto_device_info *dev_info;
> + uint32_t cap;
> + int ret;
> +
> + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> +
> + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) {
> + RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id);
> + return -EINVAL;
> + }
> +
> + adapter = eca_id_to_adapter(id);
> + if (adapter == NULL)
> + return -EINVAL;
> +
> + dev = &rte_eventdevs[adapter->eventdev_id];
> + ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id,
> + cdev_id,
> + &cap);
> + if (ret) {
> + if ((cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
> + adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ) || cap) {
> + rte_spinlock_lock(&adapter->lock);
> + ret = eca_init_service(adapter, id);
> + if (ret == 0)
> + ret = eca_add_queue_pair(adapter, cdev_id,
> + queue_pair_id);
> + rte_spinlock_unlock(&adapter->lock);
> + }
> +
> + if (ret)
> + return ret;
> +
> + rte_service_component_runstate_set(adapter->service_id, 1);
I guess, it will be called in HW case, if so, please move to appropriate
place.
> +
> + return 0;
> +}
> +
> +int __rte_experimental
> +rte_event_crypto_adapter_queue_pair_del(uint8_t id, uint8_t cdev_id,
> + int32_t queue_pair_id)
> +{
> + struct rte_event_crypto_adapter *adapter;
> + struct crypto_device_info *dev_info;
> + struct rte_eventdev *dev;
> + int ret = 0;
No need for explicit '0' assignment
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 3/6] eventdev: add crypto adapter implementation
2018-04-29 16:22 ` Jerin Jacob
@ 2018-04-30 11:18 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-30 11:18 UTC (permalink / raw)
To: Jerin Jacob
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Sunday, April 29, 2018 9:53 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> Eads, Gage <gage.eads@intel.com>
> Subject: Re: [v2,3/6] eventdev: add crypto adapter implementation
>
> -----Original Message-----
> > Date: Tue, 24 Apr 2018 18:13:24 +0530
> > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > akhil.goyal@nxp.com, dev@dpdk.org
> > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > nikhil.rao@intel.com, gage.eads@intel.com
> > Subject: [v2,3/6] eventdev: add crypto adapter implementation
> > X-Mailer: git-send-email 1.9.1
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
> > +
> > +/* Per crypto device information */
> > +struct crypto_device_info {
> > + /* Pointer to cryptodev */
> > + struct rte_cryptodev *dev;
> > + /* Pointer to queue pair info */
> > + struct crypto_queue_pair_info *qpairs;
> > + /* Next queue pair to be processed */
> > + uint16_t next_queue_pair_id;
> > + /* Set to indicate cryptodev->eventdev packet
> > + * transfer uses a hardware mechanism
> > + */
> > + uint8_t internal_event_port;
> > + /* Set to indicate processing has been started */
> > + uint8_t dev_started;
> > + /* If num_qpairs > 0, the start callback will
> > + * be invoked if not already invoked
> > + */
> > + uint16_t num_qpairs;
> > +};
>
> Looks like it is used in fastpath, if so add the cache alignment.
Sure.
>
> > +
> > +/* Per queue pair information */
> > +struct crypto_queue_pair_info {
> > + /* Set to indicate queue pair is enabled */
> > + bool qp_enabled;
> > + /* Pointer to hold rte_crypto_ops for batching */
> > + struct rte_crypto_op **op_buffer;
> > + /* No of crypto ops accumulated */
> > + uint8_t len;
> > +};
> > +
> > +static struct rte_event_crypto_adapter **event_crypto_adapter;
> > +
> > +eca_enq_to_cryptodev(struct rte_event_crypto_adapter *adapter,
> > + struct rte_event *ev, unsigned int cnt) {
> > + struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
> > + union rte_event_crypto_metadata *m_data = NULL;
> > + struct crypto_queue_pair_info *qp_info = NULL;
> > + struct rte_crypto_op *crypto_op;
> > + unsigned int i, n = 0;
> > + uint16_t qp_id = 0, len = 0, ret = 0;
>
> Please review the explicit '0' assignment.
I have initialized only those, which are complained by gcc.
I will look at it again. If required, I will initialize them separately. Is that ok?
>
> > + uint8_t cdev_id = 0;
> > +
> > + stats->event_dequeue_count += cnt;
> > +
> > + for (i = 0; i < cnt; i++) {
> > + 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_private_data(
> > + crypto_op->sym->session);
> > + 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 == NULL) {
> > + rte_pktmbuf_free(crypto_op->sym->m_src);
> > + rte_crypto_op_free(crypto_op);
> > + continue;
> > + }
> > + len = qp_info->len;
> > + qp_info->op_buffer[len] = crypto_op;
> > + len++;
> > +
> > +int __rte_experimental
> > +rte_event_crypto_adapter_queue_pair_add(uint8_t id,
> > + uint8_t cdev_id,
> > + int32_t queue_pair_id,
> > + const struct rte_event_crypto_queue_pair_conf *conf)
> {
> > + struct rte_event_crypto_adapter *adapter;
> > + struct rte_eventdev *dev;
> > + struct crypto_device_info *dev_info;
> > + uint32_t cap;
> > + int ret;
> > +
> > + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> > +
> > + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) {
> > + RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id);
> > + return -EINVAL;
> > + }
> > +
> > + adapter = eca_id_to_adapter(id);
> > + if (adapter == NULL)
> > + return -EINVAL;
> > +
> > + dev = &rte_eventdevs[adapter->eventdev_id];
> > + ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id,
> > + cdev_id,
> > + &cap);
> > + if (ret) {
> > + if ((cap &
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
> > + adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ) ||
> cap) {
> > + rte_spinlock_lock(&adapter->lock);
> > + ret = eca_init_service(adapter, id);
> > + if (ret == 0)
> > + ret = eca_add_queue_pair(adapter, cdev_id,
> > + queue_pair_id);
> > + rte_spinlock_unlock(&adapter->lock);
> > + }
> > +
> > + if (ret)
> > + return ret;
> > +
> > + rte_service_component_runstate_set(adapter->service_id, 1);
>
> I guess, it will be called in HW case, if so, please move to appropriate place.
Ok
>
> > +
> > + return 0;
> > +}
> > +
> > +int __rte_experimental
> > +rte_event_crypto_adapter_queue_pair_del(uint8_t id, uint8_t cdev_id,
> > + int32_t queue_pair_id)
> > +{
> > + struct rte_event_crypto_adapter *adapter;
> > + struct crypto_device_info *dev_info;
> > + struct rte_eventdev *dev;
> > + int ret = 0;
>
> No need for explicit '0' assignment
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test
2018-04-24 12:43 [dpdk-dev] [v2,0/6] eventdev: cover letter - crypto adapter Abhinandan Gujjar
` (2 preceding siblings ...)
2018-04-24 12:43 ` [dpdk-dev] [v2,3/6] eventdev: add crypto adapter implementation Abhinandan Gujjar
@ 2018-04-24 12:43 ` Abhinandan Gujjar
2018-04-25 14:40 ` Akhil Goyal
2018-04-24 12:43 ` [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system Abhinandan Gujjar
2018-04-24 12:43 ` [dpdk-dev] [v2,6/6] doc: add event crypto adapter documentation Abhinandan Gujjar
5 siblings, 1 reply; 29+ messages in thread
From: Abhinandan Gujjar @ 2018-04-24 12:43 UTC (permalink / raw)
To: jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, abhinandan.gujjar, nikhil.rao, gage.eads
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
---
test/test/Makefile | 1 +
test/test/test_event_crypto_adapter.c | 915 ++++++++++++++++++++++++++++++++++
2 files changed, 916 insertions(+)
create mode 100644 test/test/test_event_crypto_adapter.c
diff --git a/test/test/Makefile b/test/test/Makefile
index c9c007c9..3200daa 100644
--- a/test/test/Makefile
+++ b/test/test/Makefile
@@ -186,6 +186,7 @@ SRCS-y += test_eventdev.c
SRCS-y += test_event_ring.c
SRCS-y += test_event_eth_rx_adapter.c
SRCS-y += test_event_timer_adapter.c
+SRCS-y += test_event_crypto_adapter.c
endif
ifeq ($(CONFIG_RTE_LIBRTE_RAWDEV),y)
diff --git a/test/test/test_event_crypto_adapter.c b/test/test/test_event_crypto_adapter.c
new file mode 100644
index 0000000..ea13e3b
--- /dev/null
+++ b/test/test/test_event_crypto_adapter.c
@@ -0,0 +1,915 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#include <string.h>
+#include <rte_common.h>
+#include <rte_mempool.h>
+#include <rte_mbuf.h>
+#include <rte_cryptodev.h>
+#include <rte_eventdev.h>
+#include <rte_bus_vdev.h>
+#include <rte_service.h>
+#include <rte_event_crypto_adapter.h>
+#include "test.h"
+
+#define PKT_TRACE 0
+#define NUM 1
+#define DEFAULT_NUM_XFORMS (2)
+#define NUM_MBUFS (8191)
+#define MBUF_CACHE_SIZE (256)
+#define MAXIMUM_IV_LENGTH (16)
+#define DEFAULT_NUM_OPS_INFLIGHT (128)
+#define TEST_APP_PORT_ID 0
+#define TEST_APP_EV_QUEUE_ID 0
+#define TEST_CRYPTO_EV_QUEUE_ID 1
+#define TEST_ADAPTER_ID 0
+#define TEST_CDEV_ID 0
+#define TEST_CDEV_QP_ID 0
+#define PACKET_LENGTH 64
+#define NB_TEST_PORTS 1
+#define NB_TEST_QUEUES 2
+#define CRYPTODEV_NAME_NULL_PMD crypto_null
+
+#define MBUF_SIZE (sizeof(struct rte_mbuf) + \
+ RTE_PKTMBUF_HEADROOM + PACKET_LENGTH)
+#define IV_OFFSET (sizeof(struct rte_crypto_op) + \
+ sizeof(struct rte_crypto_sym_op) + \
+ DEFAULT_NUM_XFORMS * \
+ sizeof(struct rte_crypto_sym_xform))
+
+
+static const uint8_t text_64B[] = {
+ 0x05, 0x15, 0x77, 0x32, 0xc9, 0x66, 0x91, 0x50,
+ 0x93, 0x9f, 0xbb, 0x4e, 0x2e, 0x5a, 0x02, 0xd0,
+ 0x2d, 0x9d, 0x31, 0x5d, 0xc8, 0x9e, 0x86, 0x36,
+ 0x54, 0x5c, 0x50, 0xe8, 0x75, 0x54, 0x74, 0x5e,
+ 0xd5, 0xa2, 0x84, 0x21, 0x2d, 0xc5, 0xf8, 0x1c,
+ 0x55, 0x1a, 0xba, 0x91, 0xce, 0xb5, 0xa3, 0x1e,
+ 0x31, 0xbf, 0xe9, 0xa1, 0x97, 0x5c, 0x2b, 0xd6,
+ 0x57, 0xa5, 0x9f, 0xab, 0xbd, 0xb0, 0x9b, 0x9c
+};
+
+struct event_crypto_adapter_test_params {
+ struct rte_mempool *mbuf_pool;
+ struct rte_mempool *op_mpool;
+ struct rte_mempool *session_mpool;
+ struct rte_cryptodev_config *config;
+ uint8_t crypto_event_port_id;
+};
+
+struct rte_event response_info = {
+ .queue_id = TEST_APP_EV_QUEUE_ID,
+ .sched_type = RTE_SCHED_TYPE_ATOMIC,
+ .flow_id = 0xAABB,
+};
+
+struct rte_event_crypto_request request_info = {
+ .cdev_id = TEST_CDEV_ID,
+ .queue_pair_id = TEST_CDEV_QP_ID
+};
+
+static struct event_crypto_adapter_test_params params;
+static uint8_t crypto_adapter_setup_done;
+static uint32_t slcore_id;
+static int evdev;
+
+static struct rte_mbuf *
+alloc_fill_mbuf(struct rte_mempool *mpool, const uint8_t *data,
+ size_t len, uint8_t blocksize)
+{
+ struct rte_mbuf *m = rte_pktmbuf_alloc(mpool);
+ size_t t_len = len - (blocksize ? (len % blocksize) : 0);
+
+ if (m) {
+ char *dst = rte_pktmbuf_append(m, t_len);
+
+ if (!dst) {
+ rte_pktmbuf_free(m);
+ return NULL;
+ }
+
+ rte_memcpy(dst, (const void *)data, t_len);
+ }
+ return m;
+}
+
+static int
+send_recv_ev(struct rte_event *ev)
+{
+ struct rte_crypto_op *op;
+ struct rte_event recv_ev;
+ int ret;
+
+ ret = rte_event_enqueue_burst(evdev, TEST_APP_PORT_ID, ev, NUM);
+ TEST_ASSERT_EQUAL(ret, NUM,
+ "Failed to send event to crypto adapter\n");
+
+ while (rte_event_dequeue_burst(evdev,
+ TEST_APP_PORT_ID, &recv_ev, NUM, 0) == 0)
+ rte_pause();
+
+ op = recv_ev.event_ptr;
+#if PKT_TRACE
+ struct rte_mbuf *m = op->sym->m_src;
+ rte_pktmbuf_dump(stdout, m, rte_pktmbuf_pkt_len(m));
+#endif
+ rte_pktmbuf_free(op->sym->m_src);
+ rte_crypto_op_free(op);
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_crypto_adapter_stats(void)
+{
+ struct rte_event_crypto_adapter_stats stats;
+
+ rte_event_crypto_adapter_stats_get(TEST_ADAPTER_ID, &stats);
+ printf(" +------------------------------------------------------+\n");
+ printf(" + Crypto adapter stats for instance %u:\n", TEST_ADAPTER_ID);
+ printf(" + Event port poll count %lu\n",
+ stats.event_poll_count);
+ printf(" + Event dequeue count %lu\n",
+ stats.event_dequeue_count);
+ printf(" + Cryptodev enqueue count %lu\n",
+ stats.crypto_enq_count);
+ printf(" + Cryptodev enqueue failed count %lu\n",
+ stats.crypto_enq_fail);
+ printf(" + Cryptodev dequeue count %lu\n",
+ stats.crypto_deq_count);
+ printf(" + Event enqueue count %lu\n",
+ stats.event_enqueue_count);
+ printf(" + Event enqueue retry count %lu\n",
+ stats.event_enq_retry_count);
+ printf(" + Event enqueue fail count %lu\n",
+ stats.event_enq_fail_count);
+ printf(" +------------------------------------------------------+\n");
+
+ rte_event_crypto_adapter_stats_reset(TEST_ADAPTER_ID);
+ return TEST_SUCCESS;
+}
+
+static int
+test_enq_deq_mode(uint8_t session_less)
+{
+ struct rte_crypto_sym_xform cipher_xform;
+ struct rte_cryptodev_sym_session *sess;
+ union rte_event_crypto_metadata m_data;
+ struct rte_crypto_sym_op *sym_op;
+ struct rte_crypto_op *op;
+ struct rte_mbuf *m;
+ struct rte_event ev;
+ uint32_t cap;
+ int ret;
+
+ memset(&m_data, 0, sizeof(m_data));
+
+ m = alloc_fill_mbuf(params.mbuf_pool, text_64B, PACKET_LENGTH, 0);
+ TEST_ASSERT_NOT_NULL(m, "Failed to allocate mbuf!\n");
+#if PKT_TRACE
+ rte_pktmbuf_dump(stdout, m, rte_pktmbuf_pkt_len(m));
+#endif
+ /* Setup Cipher Parameters */
+ cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
+ cipher_xform.next = NULL;
+
+ cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
+ cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
+
+ op = rte_crypto_op_alloc(params.op_mpool,
+ RTE_CRYPTO_OP_TYPE_SYMMETRIC);
+ TEST_ASSERT_NOT_NULL(op,
+ "Failed to allocate symmetric crypto operation struct\n");
+
+ sym_op = op->sym;
+
+ if (!session_less) {
+ sess = rte_cryptodev_sym_session_create(params.session_mpool);
+ TEST_ASSERT_NOT_NULL(sess, "Session creation failed\n");
+
+ /* Create Crypto session*/
+ rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
+ &cipher_xform, params.session_mpool);
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID,
+ evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA) {
+ /* Fill in private date information */
+ rte_memcpy(&m_data.response_info, &response_info,
+ sizeof(response_info));
+ rte_memcpy(&m_data.request_info, &request_info,
+ sizeof(request_info));
+ rte_cryptodev_sym_session_set_private_data(sess,
+ &m_data, sizeof(m_data));
+ }
+
+ rte_crypto_op_attach_sym_session(op, sess);
+ } else {
+ struct rte_crypto_sym_xform *first_xform;
+
+ rte_crypto_op_sym_xforms_alloc(op, NUM);
+ op->sess_type = RTE_CRYPTO_OP_SESSIONLESS;
+ first_xform = &cipher_xform;
+ sym_op->xform = first_xform;
+ uint32_t len = IV_OFFSET + MAXIMUM_IV_LENGTH +
+ (sizeof(struct rte_crypto_sym_xform) * 2);
+ op->private_data_offset = len;
+ /* Fill in private data information */
+ rte_memcpy(&m_data.response_info, &response_info,
+ sizeof(response_info));
+ rte_memcpy(&m_data.request_info, &request_info,
+ sizeof(request_info));
+ rte_memcpy((uint8_t *)op + len, &m_data, sizeof(m_data));
+ }
+
+ sym_op->m_src = m;
+ sym_op->cipher.data.offset = 0;
+ sym_op->cipher.data.length = PACKET_LENGTH;
+
+ /* Fill in event info and update event_ptr with rte_crypto_op */
+ memset(&ev, 0, sizeof(ev));
+ ev.queue_id = TEST_CRYPTO_EV_QUEUE_ID;
+ ev.sched_type = RTE_SCHED_TYPE_ATOMIC;
+ ev.flow_id = 0xAABB;
+ ev.event_ptr = op;
+
+ ret = send_recv_ev(&ev);
+ TEST_ASSERT_SUCCESS(ret, "Failed to send/receive event to "
+ "crypto adapter\n");
+
+ test_crypto_adapter_stats();
+
+ return TEST_SUCCESS;
+}
+
+static int
+map_adapter_service_core(void)
+{
+ uint32_t adapter_service_id;
+
+ TEST_ASSERT_SUCCESS(rte_event_crypto_adapter_service_id_get(
+ TEST_ADAPTER_ID, &adapter_service_id),
+ "Failed to get event crypto adapter service id");
+
+ TEST_ASSERT_SUCCESS(rte_service_map_lcore_set(adapter_service_id,
+ slcore_id, 1), "Failed to map adapter service");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_sessionless_with_enq_deq_mode(void)
+{
+ uint32_t cap;
+ int ret;
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID, evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (!(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD))
+ map_adapter_service_core();
+
+ TEST_ASSERT_SUCCESS(rte_event_crypto_adapter_start(TEST_ADAPTER_ID),
+ "Failed to start event crypto adapter");
+
+ ret = test_enq_deq_mode(1);
+ TEST_ASSERT_SUCCESS(ret, "Sessionless - ENQ-DEQ mode test failed\n");
+ return TEST_SUCCESS;
+}
+
+static int
+test_session_with_enq_deq_mode(void)
+{
+ uint32_t cap;
+ int ret;
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID, evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (!(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD))
+ map_adapter_service_core();
+
+ TEST_ASSERT_SUCCESS(rte_event_crypto_adapter_start(TEST_ADAPTER_ID
+ ), "Failed to start event crypto adapter");
+
+ ret = test_enq_deq_mode(0);
+ TEST_ASSERT_SUCCESS(ret, "Session based - ENQ-DEQ mode test failed\n");
+ return TEST_SUCCESS;
+}
+
+static int
+send_op_recv_ev(struct rte_crypto_op *op)
+{
+ struct rte_crypto_op *recv_op;
+ struct rte_event ev;
+ int ret;
+
+ ret = rte_cryptodev_enqueue_burst(TEST_CDEV_ID, TEST_CDEV_QP_ID,
+ &op, NUM);
+ TEST_ASSERT_EQUAL(ret, NUM, "Failed to enqueue to cryptodev\n");
+ memset(&ev, 0, sizeof(ev));
+
+ while (rte_event_dequeue_burst(evdev,
+ TEST_APP_PORT_ID, &ev, NUM, 0) == 0)
+ rte_pause();
+
+ recv_op = ev.event_ptr;
+#if PKT_TRACE
+ struct rte_mbuf *m = recv_op->sym->m_src;
+ rte_pktmbuf_dump(stdout, m, rte_pktmbuf_pkt_len(m));
+#endif
+ rte_pktmbuf_free(recv_op->sym->m_src);
+ rte_crypto_op_free(recv_op);
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_deq_only_mode(uint8_t session_less)
+{
+ struct rte_crypto_sym_xform cipher_xform;
+ struct rte_cryptodev_sym_session *sess;
+ union rte_event_crypto_metadata m_data;
+ struct rte_crypto_sym_op *sym_op;
+ struct rte_crypto_op *op;
+ struct rte_mbuf *m;
+ uint32_t cap;
+ int ret;
+
+ memset(&m_data, 0, sizeof(m_data));
+
+ m = alloc_fill_mbuf(params.mbuf_pool, text_64B, PACKET_LENGTH, 0);
+ TEST_ASSERT_NOT_NULL(m, "Failed to allocate mbuf!\n");
+#if PKT_TRACE
+ rte_pktmbuf_dump(stdout, m, rte_pktmbuf_pkt_len(m));
+#endif
+ /* Setup Cipher Parameters */
+ cipher_xform.type = RTE_CRYPTO_SYM_XFORM_CIPHER;
+ cipher_xform.next = NULL;
+
+ cipher_xform.cipher.algo = RTE_CRYPTO_CIPHER_NULL;
+ cipher_xform.cipher.op = RTE_CRYPTO_CIPHER_OP_ENCRYPT;
+
+ op = rte_crypto_op_alloc(params.op_mpool,
+ RTE_CRYPTO_OP_TYPE_SYMMETRIC);
+ TEST_ASSERT_NOT_NULL(op, "Failed to allocate crypto_op!\n");
+
+ sym_op = op->sym;
+
+ if (!session_less) {
+ sess = rte_cryptodev_sym_session_create(params.session_mpool);
+ TEST_ASSERT_NOT_NULL(sess, "Session creation failed\n");
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID,
+ evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA) {
+ /* Fill in private data information */
+ rte_memcpy(&m_data.response_info, &response_info,
+ sizeof(m_data));
+ rte_cryptodev_sym_session_set_private_data(sess,
+ &m_data, sizeof(m_data));
+ }
+ rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
+ &cipher_xform, params.session_mpool);
+ rte_crypto_op_attach_sym_session(op, sess);
+ } else {
+ struct rte_crypto_sym_xform *first_xform;
+
+ rte_crypto_op_sym_xforms_alloc(op, NUM);
+ op->sess_type = RTE_CRYPTO_OP_SESSIONLESS;
+ first_xform = &cipher_xform;
+ sym_op->xform = first_xform;
+ uint32_t len = IV_OFFSET + MAXIMUM_IV_LENGTH +
+ (sizeof(struct rte_crypto_sym_xform) * 2);
+ op->private_data_offset = len;
+ /* Fill in private data information */
+ rte_memcpy(&m_data.response_info, &response_info,
+ sizeof(m_data));
+ rte_memcpy((uint8_t *)op + len, &m_data, sizeof(m_data));
+ }
+
+ sym_op->m_src = m;
+ sym_op->cipher.data.offset = 0;
+ sym_op->cipher.data.length = PACKET_LENGTH;
+
+ ret = send_op_recv_ev(op);
+ TEST_ASSERT_SUCCESS(ret, "Failed to enqueue op to cryptodev\n");
+
+ test_crypto_adapter_stats();
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_sessionless_with_deq_only_mode(void)
+{
+ uint32_t cap;
+ int ret;
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID, evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (!(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) ||
+ !(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW))
+ map_adapter_service_core();
+
+ /* start the event crypto adapter */
+ TEST_ASSERT_SUCCESS(rte_event_crypto_adapter_start(TEST_ADAPTER_ID),
+ "Failed to start event crypto adapter");
+
+ ret = test_deq_only_mode(1);
+ TEST_ASSERT_SUCCESS(ret, "Sessionless - DEQ_ONLY test failed\n");
+ return TEST_SUCCESS;
+}
+
+static int
+test_session_with_deq_only_mode(void)
+{
+ uint32_t cap;
+ int ret;
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID, evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (!(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_FWD) ||
+ !(cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW))
+ map_adapter_service_core();
+
+ TEST_ASSERT_SUCCESS(rte_event_crypto_adapter_start(TEST_ADAPTER_ID),
+ "Failed to start event crypto adapter");
+
+ ret = test_deq_only_mode(0);
+ TEST_ASSERT_SUCCESS(ret, "Session based - DEQ_ONLY test failed\n");
+ return TEST_SUCCESS;
+}
+
+static int
+configure_cryptodev(void)
+{
+ struct rte_cryptodev_qp_conf qp_conf;
+ struct rte_cryptodev_config conf;
+ struct rte_cryptodev_info info;
+ unsigned int session_size;
+ uint8_t nb_devs;
+ int ret;
+
+ params.mbuf_pool = rte_pktmbuf_pool_create(
+ "CRYPTO_ADAPTER_MBUFPOOL",
+ NUM_MBUFS, MBUF_CACHE_SIZE, 0, MBUF_SIZE,
+ rte_socket_id());
+ if (params.mbuf_pool == NULL) {
+ RTE_LOG(ERR, USER1, "Can't create CRYPTO_MBUFPOOL\n");
+ return TEST_FAILED;
+ }
+
+ params.op_mpool = rte_crypto_op_pool_create(
+ "EVENT_CRYPTO_SYM_OP_POOL",
+ RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ NUM_MBUFS, MBUF_CACHE_SIZE,
+ DEFAULT_NUM_XFORMS *
+ sizeof(struct rte_crypto_sym_xform) +
+ MAXIMUM_IV_LENGTH,
+ rte_socket_id());
+ if (params.op_mpool == NULL) {
+ RTE_LOG(ERR, USER1, "Can't create CRYPTO_OP_POOL\n");
+ return TEST_FAILED;
+ }
+
+ /* Create a NULL crypto device */
+ nb_devs = rte_cryptodev_device_count_by_driver(
+ rte_cryptodev_driver_id_get(
+ RTE_STR(CRYPTODEV_NAME_NULL_PMD)));
+ if (!nb_devs) {
+ ret = rte_vdev_init(
+ RTE_STR(CRYPTODEV_NAME_NULL_PMD), NULL);
+
+ TEST_ASSERT(ret == 0, "Failed to create pmd:%s instance\n",
+ RTE_STR(CRYPTODEV_NAME_NULL_PMD));
+ }
+
+ nb_devs = rte_cryptodev_count();
+ if (!nb_devs) {
+ RTE_LOG(ERR, USER1, "No crypto devices found?\n");
+ return TEST_FAILED;
+ }
+
+ /*
+ * Create mempool with maximum number of sessions * 2,
+ * to include the session headers & private data
+ */
+ session_size = rte_cryptodev_get_private_session_size(TEST_CDEV_ID);
+ session_size += sizeof(union rte_event_crypto_metadata);
+
+ params.session_mpool = rte_mempool_create(
+ "CRYPTO_ADAPTER_SESSION_MP",
+ info.sym.max_nb_sessions * 2,
+ session_size,
+ 0, 0, NULL, NULL, NULL,
+ NULL, SOCKET_ID_ANY,
+ 0);
+
+ TEST_ASSERT_NOT_NULL(params.session_mpool,
+ "session mempool allocation failed\n");
+
+ rte_cryptodev_info_get(TEST_CDEV_ID, &info);
+ conf.nb_queue_pairs = info.max_nb_queue_pairs;
+ conf.socket_id = SOCKET_ID_ANY;
+
+ TEST_ASSERT_SUCCESS(rte_cryptodev_configure(TEST_CDEV_ID,
+ &conf),
+ "Failed to configure cryptodev %u with %u qps\n",
+ TEST_CDEV_ID, conf.nb_queue_pairs);
+
+ qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+
+ TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
+ TEST_CDEV_ID, TEST_CDEV_QP_ID, &qp_conf,
+ rte_cryptodev_socket_id(TEST_CDEV_ID),
+ params.session_mpool),
+ "Failed to setup queue pair %u on cryptodev %u\n",
+ TEST_CDEV_QP_ID, TEST_CDEV_ID);
+
+ return TEST_SUCCESS;
+}
+
+static inline void
+evdev_set_conf_values(struct rte_event_dev_config *dev_conf,
+ struct rte_event_dev_info *info)
+{
+ memset(dev_conf, 0, sizeof(struct rte_event_dev_config));
+ dev_conf->dequeue_timeout_ns = info->min_dequeue_timeout_ns;
+ dev_conf->nb_event_ports = NB_TEST_PORTS;
+ dev_conf->nb_event_queues = NB_TEST_QUEUES;
+ dev_conf->nb_event_queue_flows = info->max_event_queue_flows;
+ dev_conf->nb_event_port_dequeue_depth =
+ info->max_event_port_dequeue_depth;
+ dev_conf->nb_event_port_enqueue_depth =
+ info->max_event_port_enqueue_depth;
+ dev_conf->nb_event_port_enqueue_depth =
+ info->max_event_port_enqueue_depth;
+ dev_conf->nb_events_limit =
+ info->max_num_events;
+}
+
+static int
+configure_eventdev(void)
+{
+ const char *eventdev_name = "event_sw0";
+ struct rte_event_queue_conf queue_conf;
+ struct rte_event_dev_config devconf;
+ struct rte_event_dev_info info;
+ uint32_t queue_count;
+ uint32_t port_count;
+ int ret;
+ uint8_t qid;
+
+ evdev = rte_event_dev_get_dev_id(eventdev_name);
+ if (evdev < 0) {
+ if (rte_vdev_init(eventdev_name, NULL) < 0) {
+ RTE_LOG(DEBUG, USER1, "Error creating eventdev\n");
+ return TEST_FAILED;
+ }
+ evdev = rte_event_dev_get_dev_id(eventdev_name);
+ if (evdev < 0) {
+ RTE_LOG(DEBUG, USER1, "Error finding eventdev!\n");
+ return TEST_FAILED;
+ }
+ }
+
+ ret = rte_event_dev_info_get(evdev, &info);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get event dev info\n");
+
+ evdev_set_conf_values(&devconf, &info);
+
+ ret = rte_event_dev_configure(evdev, &devconf);
+ TEST_ASSERT_SUCCESS(ret, "Failed to configure eventdev\n");
+
+ /* Set up event queue */
+ ret = rte_event_dev_attr_get(evdev, RTE_EVENT_DEV_ATTR_QUEUE_COUNT,
+ &queue_count);
+ TEST_ASSERT_SUCCESS(ret, "Queue count get failed\n");
+ TEST_ASSERT_EQUAL(queue_count, 2, "Unexpected queue count\n");
+
+ qid = TEST_APP_EV_QUEUE_ID;
+ ret = rte_event_queue_setup(evdev, qid, NULL);
+ TEST_ASSERT_SUCCESS(ret, "Failed to setup queue=%d\n", qid);
+
+ queue_conf.nb_atomic_flows = info.max_event_queue_flows;
+ queue_conf.nb_atomic_order_sequences = 32;
+ queue_conf.schedule_type = RTE_SCHED_TYPE_ATOMIC;
+ queue_conf.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST;
+ queue_conf.event_queue_cfg = RTE_EVENT_QUEUE_CFG_SINGLE_LINK;
+
+ qid = TEST_CRYPTO_EV_QUEUE_ID;
+ ret = rte_event_queue_setup(evdev, qid, &queue_conf);
+ TEST_ASSERT_SUCCESS(ret, "Failed to setup queue=%u\n", qid);
+
+ /* Set up event port */
+ ret = rte_event_dev_attr_get(evdev, RTE_EVENT_DEV_ATTR_PORT_COUNT,
+ &port_count);
+ TEST_ASSERT_SUCCESS(ret, "Port count get failed\n");
+ TEST_ASSERT_EQUAL(port_count, 1, "Unexpected port count\n");
+
+ ret = rte_event_port_setup(evdev, TEST_APP_PORT_ID, NULL);
+ TEST_ASSERT_SUCCESS(ret, "Failed to setup port=%d\n",
+ TEST_APP_PORT_ID);
+
+ qid = TEST_APP_EV_QUEUE_ID;
+ ret = rte_event_port_link(evdev, TEST_APP_PORT_ID, &qid, NULL, 1);
+ TEST_ASSERT(ret >= 0, "Failed to link queue port=%d\n",
+ TEST_APP_PORT_ID);
+
+ return TEST_SUCCESS;
+}
+
+static void
+test_crypto_adapter_free(void)
+{
+ rte_event_crypto_adapter_free(TEST_ADAPTER_ID);
+}
+
+static int
+test_crypto_adapter_create(void)
+{
+ struct rte_event_port_conf conf = {
+ .dequeue_depth = 8,
+ .enqueue_depth = 8,
+ .new_event_threshold = 1200,
+ };
+ int ret;
+
+ /* Create adapter with default port creation callback */
+ ret = rte_event_crypto_adapter_create(TEST_ADAPTER_ID,
+ TEST_CDEV_ID,
+ &conf, 0);
+ TEST_ASSERT_SUCCESS(ret, "Failed to create event crypto adapter\n");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_crypto_adapter_qp_add_del(void)
+{
+ uint32_t cap;
+ int ret;
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID, evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND) {
+ struct rte_event_crypto_queue_pair_conf conf = {
+ .ev = response_info
+ };
+ ret = rte_event_crypto_adapter_queue_pair_add(TEST_ADAPTER_ID,
+ TEST_CDEV_ID, TEST_CDEV_QP_ID, &conf);
+ } else
+ ret = rte_event_crypto_adapter_queue_pair_add(TEST_ADAPTER_ID,
+ TEST_CDEV_ID, TEST_CDEV_QP_ID, NULL);
+
+ TEST_ASSERT_SUCCESS(ret, "Failed to create add queue pair\n");
+
+ ret = rte_event_crypto_adapter_queue_pair_del(TEST_ADAPTER_ID,
+ TEST_CDEV_ID, TEST_CDEV_QP_ID);
+ TEST_ASSERT_SUCCESS(ret, "Failed to delete add queue pair\n");
+
+ return TEST_SUCCESS;
+}
+
+static int
+configure_event_crypto_adapter(enum rte_event_crypto_adapter_mode mode)
+{
+ struct rte_event_port_conf conf = {
+ .dequeue_depth = 8,
+ .enqueue_depth = 8,
+ .new_event_threshold = 1200,
+ };
+
+ uint32_t cap;
+ int ret;
+
+ /* Create adapter with default port creation callback */
+ ret = rte_event_crypto_adapter_create(TEST_ADAPTER_ID,
+ TEST_CDEV_ID,
+ &conf, mode);
+ TEST_ASSERT_SUCCESS(ret, "Failed to create event crypto adapter\n");
+
+ ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID, evdev, &cap);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get adapter capabilities\n");
+
+ if (cap & RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_QP_EV_BIND) {
+ struct rte_event_crypto_queue_pair_conf conf = {
+ .ev = response_info
+ };
+ ret = rte_event_crypto_adapter_queue_pair_add(TEST_ADAPTER_ID,
+ TEST_CDEV_ID, TEST_CDEV_QP_ID, &conf);
+ } else
+ ret = rte_event_crypto_adapter_queue_pair_add(TEST_ADAPTER_ID,
+ TEST_CDEV_ID, TEST_CDEV_QP_ID, NULL);
+
+ TEST_ASSERT_SUCCESS(ret, "Failed to add queue pair\n");
+
+ ret = rte_event_crypto_adapter_event_port_get(TEST_ADAPTER_ID,
+ ¶ms.crypto_event_port_id);
+ TEST_ASSERT_SUCCESS(ret, "Failed to get event port\n");
+
+ return TEST_SUCCESS;
+}
+
+static void
+test_crypto_adapter_stop(void)
+{
+ uint32_t evdev_service_id, adapter_service_id;
+
+ /* retrieve service ids */
+ rte_event_dev_service_id_get(evdev, &evdev_service_id);
+ rte_event_crypto_adapter_service_id_get(
+ TEST_ADAPTER_ID, &adapter_service_id);
+
+ /* stop services */
+ rte_service_runstate_set(evdev_service_id, 0);
+ rte_service_runstate_set(adapter_service_id, 0);
+ rte_service_lcore_stop(slcore_id);
+ rte_service_lcore_del(slcore_id);
+ rte_event_crypto_adapter_stop(TEST_ADAPTER_ID);
+ rte_event_dev_stop(evdev);
+}
+
+static int
+test_crypto_adapter_conf(enum rte_event_crypto_adapter_mode mode)
+{
+ uint32_t evdev_service_id;
+ uint8_t qid;
+ int ret;
+
+ if (!crypto_adapter_setup_done) {
+ ret = configure_event_crypto_adapter(mode);
+ if (!ret) {
+ qid = TEST_CRYPTO_EV_QUEUE_ID;
+ ret = rte_event_port_link(evdev,
+ params.crypto_event_port_id, &qid, NULL, 1);
+ TEST_ASSERT(ret >= 0, "Failed to link queue %d "
+ "port=%u\n", qid,
+ params.crypto_event_port_id);
+ }
+ crypto_adapter_setup_done = 1;
+ }
+
+ /* retrieve service ids */
+ TEST_ASSERT_SUCCESS(rte_event_dev_service_id_get(evdev,
+ &evdev_service_id), "Failed to get event device "
+ "service id");
+
+ /* add a service core and start it */
+ TEST_ASSERT_SUCCESS(rte_service_lcore_add(slcore_id),
+ "Failed to add service core");
+ TEST_ASSERT_SUCCESS(rte_service_lcore_start(slcore_id),
+ "Failed to start service core");
+
+ /* map services to it */
+ TEST_ASSERT_SUCCESS(rte_service_map_lcore_set(evdev_service_id,
+ slcore_id, 1), "Failed to map evdev service");
+
+ /* set services to running */
+ TEST_ASSERT_SUCCESS(rte_service_runstate_set(evdev_service_id, 1),
+ "Failed to start evdev service");
+
+ /* start the eventdev */
+ TEST_ASSERT_SUCCESS(rte_event_dev_start(evdev),
+ "Failed to start event device");
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_crypto_adapter_conf_enq_deq_mode(void)
+{
+ enum rte_event_crypto_adapter_mode mode;
+
+ mode = RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ;
+ test_crypto_adapter_conf(mode);
+
+ return TEST_SUCCESS;
+}
+
+static int
+test_crypto_adapter_conf_deq_only_mode(void)
+{
+ enum rte_event_crypto_adapter_mode mode;
+
+ mode = RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY;
+ test_crypto_adapter_conf(mode);
+ return TEST_SUCCESS;
+}
+
+
+static int
+testsuite_setup(void)
+{
+ int ret;
+
+ slcore_id = rte_get_next_lcore(-1, 1, 0);
+ TEST_ASSERT_NOT_EQUAL(slcore_id, RTE_MAX_LCORE, "At least 2 lcores "
+ "are required to run this autotest\n");
+
+ /* Setup and start event device. */
+ ret = configure_eventdev();
+ TEST_ASSERT_SUCCESS(ret, "Failed to setup eventdev\n");
+
+ /* Setup and start crypto device. */
+ ret = configure_cryptodev();
+ TEST_ASSERT_SUCCESS(ret, "cryptodev initialization failed\n");
+
+ return TEST_SUCCESS;
+}
+
+static void
+crypto_teardown(void)
+{
+ /* Free mbuf mempool */
+ if (params.mbuf_pool != NULL) {
+ RTE_LOG(DEBUG, USER1, "CRYPTO_ADAPTER_MBUFPOOL count %u\n",
+ rte_mempool_avail_count(params.mbuf_pool));
+ rte_mempool_free(params.mbuf_pool);
+ params.mbuf_pool = NULL;
+ }
+
+ /* Free session mempool */
+ if (params.session_mpool != NULL) {
+ RTE_LOG(DEBUG, USER1, "CRYPTO_ADAPTER_SESSION_MP count %u\n",
+ rte_mempool_avail_count(params.session_mpool));
+ rte_mempool_free(params.session_mpool);
+ params.session_mpool = NULL;
+ }
+
+ /* Free ops mempool */
+ if (params.op_mpool != NULL) {
+ RTE_LOG(DEBUG, USER1, "EVENT_CRYPTO_SYM_OP_POOL count %u\n",
+ rte_mempool_avail_count(params.op_mpool));
+ rte_mempool_free(params.op_mpool);
+ params.op_mpool = NULL;
+ }
+}
+
+static void
+eventdev_teardown(void)
+{
+ rte_event_dev_stop(evdev);
+}
+
+static void
+testsuite_teardown(void)
+{
+ crypto_teardown();
+ eventdev_teardown();
+}
+
+static struct unit_test_suite service_tests = {
+ .suite_name = "Event crypto adapter test suite",
+ .setup = testsuite_setup,
+ .teardown = testsuite_teardown,
+ .unit_test_cases = {
+
+ TEST_CASE_ST(NULL, test_crypto_adapter_free,
+ test_crypto_adapter_create),
+
+ TEST_CASE_ST(test_crypto_adapter_create,
+ test_crypto_adapter_free,
+ test_crypto_adapter_qp_add_del),
+
+ TEST_CASE_ST(test_crypto_adapter_create,
+ test_crypto_adapter_free,
+ test_crypto_adapter_stats),
+
+ TEST_CASE_ST(test_crypto_adapter_conf_enq_deq_mode,
+ test_crypto_adapter_stop,
+ test_session_with_enq_deq_mode),
+
+ TEST_CASE_ST(test_crypto_adapter_conf_enq_deq_mode,
+ test_crypto_adapter_stop,
+ test_sessionless_with_enq_deq_mode),
+
+ TEST_CASE_ST(test_crypto_adapter_conf_deq_only_mode,
+ test_crypto_adapter_stop,
+ test_session_with_deq_only_mode),
+
+ TEST_CASE_ST(test_crypto_adapter_conf_deq_only_mode,
+ test_crypto_adapter_stop,
+ test_sessionless_with_deq_only_mode),
+
+ TEST_CASES_END() /**< NULL terminate unit test array */
+ }
+};
+
+static int
+test_event_crypto_adapter(void)
+{
+ return unit_test_suite_runner(&service_tests);
+}
+
+REGISTER_TEST_COMMAND(event_crypto_adapter_autotest,
+ test_event_crypto_adapter);
--
1.9.1
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test
2018-04-24 12:43 ` [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test Abhinandan Gujjar
@ 2018-04-25 14:40 ` Akhil Goyal
2018-04-26 4:58 ` Gujjar, Abhinandan S
0 siblings, 1 reply; 29+ messages in thread
From: Akhil Goyal @ 2018-04-25 14:40 UTC (permalink / raw)
To: Abhinandan Gujjar, jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, nikhil.rao, gage.eads
Hi Abhinandan,
On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> test/test/Makefile | 1 +
> test/test/test_event_crypto_adapter.c | 915 ++++++++++++++++++++++++++++++++++
> 2 files changed, 916 insertions(+)
> create mode 100644 test/test/test_event_crypto_adapter.c
>
> diff --git a/test/test/Makefile b/test/test/Makefile
> index c9c007c9..3200daa 100644
> --- a/test/test/Makefile
> +++ b/test/test/Makefile
> @@ -186,6 +186,7 @@ SRCS-y += test_eventdev.c
> SRCS-y += test_event_ring.c
> SRCS-y += test_event_eth_rx_adapter.c
> SRCS-y += test_event_timer_adapter.c
> +SRCS-y += test_event_crypto_adapter.c
> endif
>
> ifeq ($(CONFIG_RTE_LIBRTE_RAWDEV),y)
> diff --git a/test/test/test_event_crypto_adapter.c b/test/test/test_event_crypto_adapter.c
> new file mode 100644
> index 0000000..ea13e3b
> --- /dev/null
> +++ b/test/test/test_event_crypto_adapter.c
> @@ -0,0 +1,915 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Intel Corporation
> + */
> +
> +#include <string.h>
> +#include <rte_common.h>
> +#include <rte_mempool.h>
> +#include <rte_mbuf.h>
> +#include <rte_cryptodev.h>
> +#include <rte_eventdev.h>
> +#include <rte_bus_vdev.h>
> +#include <rte_service.h>
> +#include <rte_event_crypto_adapter.h>
> +#include "test.h"
> +
> +#define PKT_TRACE 0
> +#define NUM 1
> +#define DEFAULT_NUM_XFORMS (2)
> +#define NUM_MBUFS (8191)
> +#define MBUF_CACHE_SIZE (256)
> +#define MAXIMUM_IV_LENGTH (16)
> +#define DEFAULT_NUM_OPS_INFLIGHT (128)
> +#define TEST_APP_PORT_ID 0
> +#define TEST_APP_EV_QUEUE_ID 0
> +#define TEST_CRYPTO_EV_QUEUE_ID 1
> +#define TEST_ADAPTER_ID 0
> +#define TEST_CDEV_ID 0
> +#define TEST_CDEV_QP_ID 0
> +#define PACKET_LENGTH 64
> +#define NB_TEST_PORTS 1
> +#define NB_TEST_QUEUES 2
> +#define CRYPTODEV_NAME_NULL_PMD crypto_null
I think the supported cryptodevs should be more than just null
It should be done similar to other test and example applications.
> +
> +#define MBUF_SIZE (sizeof(struct rte_mbuf) + \
> + RTE_PKTMBUF_HEADROOM + PACKET_LENGTH)
> +#define IV_OFFSET (sizeof(struct rte_crypto_op) + \
> + sizeof(struct rte_crypto_sym_op) + \
> + DEFAULT_NUM_XFORMS * \
> + sizeof(struct rte_crypto_sym_xform))
> +
> +
> +static const uint8_t text_64B[] = {
> + 0x05, 0x15, 0x77, 0x32, 0xc9, 0x66, 0x91, 0x50,
> + 0x93, 0x9f, 0xbb, 0x4e, 0x2e, 0x5a, 0x02, 0xd0,
> + 0x2d, 0x9d, 0x31, 0x5d, 0xc8, 0x9e, 0x86, 0x36,
> + 0x54, 0x5c, 0x50, 0xe8, 0x75, 0x54, 0x74, 0x5e,
> + 0xd5, 0xa2, 0x84, 0x21, 0x2d, 0xc5, 0xf8, 0x1c,
> + 0x55, 0x1a, 0xba, 0x91, 0xce, 0xb5, 0xa3, 0x1e,
> + 0x31, 0xbf, 0xe9, 0xa1, 0x97, 0x5c, 0x2b, 0xd6,
> + 0x57, 0xa5, 0x9f, 0xab, 0xbd, 0xb0, 0x9b, 0x9c
> +};
> +
> +struct event_crypto_adapter_test_params {
> + struct rte_mempool *mbuf_pool;
> + struct rte_mempool *op_mpool;
> + struct rte_mempool *session_mpool;
> + struct rte_cryptodev_config *config;
> + uint8_t crypto_event_port_id;
> +};
> +
> +struct rte_event response_info = {
> + .queue_id = TEST_APP_EV_QUEUE_ID,
> + .sched_type = RTE_SCHED_TYPE_ATOMIC,
> + .flow_id = 0xAABB,
I believe all fields shall be filled here. In some GCC version it will
give warning.
> +};
> +
> +struct rte_event_crypto_request request_info = {
> + .cdev_id = TEST_CDEV_ID,
> + .queue_pair_id = TEST_CDEV_QP_ID
> +};
> +
> +static struct event_crypto_adapter_test_params params;
> +static uint8_t crypto_adapter_setup_done;
> +static uint32_t slcore_id;
> +static int evdev;
> +
Regards,
Akhil
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test
2018-04-25 14:40 ` Akhil Goyal
@ 2018-04-26 4:58 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-26 4:58 UTC (permalink / raw)
To: Akhil Goyal, jerin.jacob, hemant.agrawal, dev
Cc: Vangati, Narender, Rao, Nikhil, Eads, Gage
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, April 25, 2018 8:10 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com;
> akhil.goyal@nxp.com; dev@dpdk.org
> Cc: Vangati, Narender <narender.vangati@intel.com>; Rao, Nikhil
> <nikhil.rao@intel.com>; Eads, Gage <gage.eads@intel.com>
> Subject: Re: [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test
>
> Hi Abhinandan,
> On 4/24/2018 6:13 PM, Abhinandan Gujjar wrote:
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > test/test/Makefile | 1 +
> > test/test/test_event_crypto_adapter.c | 915
> > ++++++++++++++++++++++++++++++++++
> > 2 files changed, 916 insertions(+)
> > create mode 100644 test/test/test_event_crypto_adapter.c
> >
> > diff --git a/test/test/Makefile b/test/test/Makefile index
> > c9c007c9..3200daa 100644
> > --- a/test/test/Makefile
> > +++ b/test/test/Makefile
> > @@ -186,6 +186,7 @@ SRCS-y += test_eventdev.c SRCS-y +=
> > test_event_ring.c SRCS-y += test_event_eth_rx_adapter.c SRCS-y +=
> > test_event_timer_adapter.c
> > +SRCS-y += test_event_crypto_adapter.c
> > endif
> >
> > ifeq ($(CONFIG_RTE_LIBRTE_RAWDEV),y)
> > diff --git a/test/test/test_event_crypto_adapter.c
> > b/test/test/test_event_crypto_adapter.c
> > new file mode 100644
> > index 0000000..ea13e3b
> > --- /dev/null
> > +++ b/test/test/test_event_crypto_adapter.c
> > @@ -0,0 +1,915 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2018 Intel Corporation */
> > +
> > +#include <string.h>
> > +#include <rte_common.h>
> > +#include <rte_mempool.h>
> > +#include <rte_mbuf.h>
> > +#include <rte_cryptodev.h>
> > +#include <rte_eventdev.h>
> > +#include <rte_bus_vdev.h>
> > +#include <rte_service.h>
> > +#include <rte_event_crypto_adapter.h> #include "test.h"
> > +
> > +#define PKT_TRACE 0
> > +#define NUM 1
> > +#define DEFAULT_NUM_XFORMS (2)
> > +#define NUM_MBUFS (8191)
> > +#define MBUF_CACHE_SIZE (256)
> > +#define MAXIMUM_IV_LENGTH (16)
> > +#define DEFAULT_NUM_OPS_INFLIGHT (128)
> > +#define TEST_APP_PORT_ID 0
> > +#define TEST_APP_EV_QUEUE_ID 0
> > +#define TEST_CRYPTO_EV_QUEUE_ID 1
> > +#define TEST_ADAPTER_ID 0
> > +#define TEST_CDEV_ID 0
> > +#define TEST_CDEV_QP_ID 0
> > +#define PACKET_LENGTH 64
> > +#define NB_TEST_PORTS 1
> > +#define NB_TEST_QUEUES 2
> > +#define CRYPTODEV_NAME_NULL_PMD crypto_null
> I think the supported cryptodevs should be more than just null It should be done
> similar to other test and example applications.
My intension is to have minimal cryptodev code and emphasis more
on adapter part. More of cryptodev, will make test more complex.
That's the reason for choosing NULL cryptodev.
Anyway, depending upon chosen cryptodev the adapter code should still work.
> > +
> > +#define MBUF_SIZE (sizeof(struct rte_mbuf) + \
> > + RTE_PKTMBUF_HEADROOM +
> PACKET_LENGTH)
> > +#define IV_OFFSET (sizeof(struct rte_crypto_op) + \
> > + sizeof(struct rte_crypto_sym_op) + \
> > + DEFAULT_NUM_XFORMS * \
> > + sizeof(struct rte_crypto_sym_xform))
> > +
> > +
> > +static const uint8_t text_64B[] = {
> > + 0x05, 0x15, 0x77, 0x32, 0xc9, 0x66, 0x91, 0x50,
> > + 0x93, 0x9f, 0xbb, 0x4e, 0x2e, 0x5a, 0x02, 0xd0,
> > + 0x2d, 0x9d, 0x31, 0x5d, 0xc8, 0x9e, 0x86, 0x36,
> > + 0x54, 0x5c, 0x50, 0xe8, 0x75, 0x54, 0x74, 0x5e,
> > + 0xd5, 0xa2, 0x84, 0x21, 0x2d, 0xc5, 0xf8, 0x1c,
> > + 0x55, 0x1a, 0xba, 0x91, 0xce, 0xb5, 0xa3, 0x1e,
> > + 0x31, 0xbf, 0xe9, 0xa1, 0x97, 0x5c, 0x2b, 0xd6,
> > + 0x57, 0xa5, 0x9f, 0xab, 0xbd, 0xb0, 0x9b, 0x9c };
> > +
> > +struct event_crypto_adapter_test_params {
> > + struct rte_mempool *mbuf_pool;
> > + struct rte_mempool *op_mpool;
> > + struct rte_mempool *session_mpool;
> > + struct rte_cryptodev_config *config;
> > + uint8_t crypto_event_port_id;
> > +};
> > +
> > +struct rte_event response_info = {
> > + .queue_id = TEST_APP_EV_QUEUE_ID,
> > + .sched_type = RTE_SCHED_TYPE_ATOMIC,
> > + .flow_id = 0xAABB,
> I believe all fields shall be filled here. In some GCC version it will give warning.
Ok.
Regards
Abhinandan
> > +};
> > +
> > +struct rte_event_crypto_request request_info = {
> > + .cdev_id = TEST_CDEV_ID,
> > + .queue_pair_id = TEST_CDEV_QP_ID
> > +};
> > +
> > +static struct event_crypto_adapter_test_params params; static uint8_t
> > +crypto_adapter_setup_done; static uint32_t slcore_id; static int
> > +evdev;
> > +
>
> Regards,
> Akhil
^ permalink raw reply [flat|nested] 29+ messages in thread
* [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system
2018-04-24 12:43 [dpdk-dev] [v2,0/6] eventdev: cover letter - crypto adapter Abhinandan Gujjar
` (3 preceding siblings ...)
2018-04-24 12:43 ` [dpdk-dev] [v2,4/6] test: add event crypto adapter auto-test Abhinandan Gujjar
@ 2018-04-24 12:43 ` Abhinandan Gujjar
2018-04-29 16:25 ` Jerin Jacob
2018-04-24 12:43 ` [dpdk-dev] [v2,6/6] doc: add event crypto adapter documentation Abhinandan Gujjar
5 siblings, 1 reply; 29+ messages in thread
From: Abhinandan Gujjar @ 2018-04-24 12:43 UTC (permalink / raw)
To: jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, abhinandan.gujjar, nikhil.rao, gage.eads
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
---
lib/librte_eventdev/meson.build | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eventdev/meson.build b/lib/librte_eventdev/meson.build
index 232b870..df9be41 100644
--- a/lib/librte_eventdev/meson.build
+++ b/lib/librte_eventdev/meson.build
@@ -6,7 +6,8 @@ allow_experimental_apis = true
sources = files('rte_eventdev.c',
'rte_event_ring.c',
'rte_event_eth_rx_adapter.c',
- 'rte_event_timer_adapter.c')
+ 'rte_event_timer_adapter.c',
+ 'rte_event_crypto_adapter.c')
headers = files('rte_eventdev.h',
'rte_eventdev_pmd.h',
'rte_eventdev_pmd_pci.h',
@@ -14,5 +15,6 @@ headers = files('rte_eventdev.h',
'rte_event_ring.h',
'rte_event_eth_rx_adapter.h',
'rte_event_timer_adapter.h',
- 'rte_event_timer_adapter_pmd.h')
-deps += ['ring', 'ethdev', 'hash', 'mempool', 'timer']
+ 'rte_event_timer_adapter_pmd.h',
+ 'rte_event_crypto_adapter.h')
+deps += ['ring', 'ethdev', 'hash', 'mempool', 'timer', 'cryptodev']
--
1.9.1
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system
2018-04-24 12:43 ` [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system Abhinandan Gujjar
@ 2018-04-29 16:25 ` Jerin Jacob
2018-04-30 11:21 ` Gujjar, Abhinandan S
0 siblings, 1 reply; 29+ messages in thread
From: Jerin Jacob @ 2018-04-29 16:25 UTC (permalink / raw)
To: Abhinandan Gujjar
Cc: hemant.agrawal, akhil.goyal, dev, narender.vangati, nikhil.rao,
gage.eads
-----Original Message-----
> Date: Tue, 24 Apr 2018 18:13:26 +0530
> From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> akhil.goyal@nxp.com, dev@dpdk.org
> CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> nikhil.rao@intel.com, gage.eads@intel.com
> Subject: [v2,5/6] eventdev: add event crypto adapter to meson build system
> X-Mailer: git-send-email 1.9.1
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> lib/librte_eventdev/meson.build | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_eventdev/meson.build b/lib/librte_eventdev/meson.build
Separate patch is not required for meson build. Have it in the same patch
for make based build and ADD each files as when it added in the patch.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system
2018-04-29 16:25 ` Jerin Jacob
@ 2018-04-30 11:21 ` Gujjar, Abhinandan S
2018-04-30 11:27 ` Jerin Jacob
0 siblings, 1 reply; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-30 11:21 UTC (permalink / raw)
To: Jerin Jacob
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Sunday, April 29, 2018 9:55 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> Eads, Gage <gage.eads@intel.com>
> Subject: Re: [v2,5/6] eventdev: add event crypto adapter to meson build system
>
> -----Original Message-----
> > Date: Tue, 24 Apr 2018 18:13:26 +0530
> > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > akhil.goyal@nxp.com, dev@dpdk.org
> > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > nikhil.rao@intel.com, gage.eads@intel.com
> > Subject: [v2,5/6] eventdev: add event crypto adapter to meson build
> > system
> > X-Mailer: git-send-email 1.9.1
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > lib/librte_eventdev/meson.build | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_eventdev/meson.build
> > b/lib/librte_eventdev/meson.build
>
> Separate patch is not required for meson build. Have it in the same patch for
> make based build and ADD each files as when it added in the patch.
Should I add changes related to " lib/librte_eventdev/meson.build" as part of crypto adapter implementation?
Or you recommend the changes in "eventdev pmd" patch?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system
2018-04-30 11:21 ` Gujjar, Abhinandan S
@ 2018-04-30 11:27 ` Jerin Jacob
0 siblings, 0 replies; 29+ messages in thread
From: Jerin Jacob @ 2018-04-30 11:27 UTC (permalink / raw)
To: Gujjar, Abhinandan S
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
-----Original Message-----
> Date: Mon, 30 Apr 2018 11:21:38 +0000
> From: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
> "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, "dev@dpdk.org"
> <dev@dpdk.org>, "Vangati, Narender" <narender.vangati@intel.com>, "Rao,
> Nikhil" <nikhil.rao@intel.com>, "Eads, Gage" <gage.eads@intel.com>
> Subject: RE: [v2,5/6] eventdev: add event crypto adapter to meson build
> system
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Sunday, April 29, 2018 9:55 PM
> > To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> > Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> > Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> > Eads, Gage <gage.eads@intel.com>
> > Subject: Re: [v2,5/6] eventdev: add event crypto adapter to meson build system
> >
> > -----Original Message-----
> > > Date: Tue, 24 Apr 2018 18:13:26 +0530
> > > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > > akhil.goyal@nxp.com, dev@dpdk.org
> > > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > > nikhil.rao@intel.com, gage.eads@intel.com
> > > Subject: [v2,5/6] eventdev: add event crypto adapter to meson build
> > > system
> > > X-Mailer: git-send-email 1.9.1
> > >
> > > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > > ---
> > > lib/librte_eventdev/meson.build | 8 +++++---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/lib/librte_eventdev/meson.build
> > > b/lib/librte_eventdev/meson.build
> >
> > Separate patch is not required for meson build. Have it in the same patch for
> > make based build and ADD each files as when it added in the patch.
> Should I add changes related to " lib/librte_eventdev/meson.build" as part of crypto adapter implementation?
> Or you recommend the changes in "eventdev pmd" patch?
IMO, You can add in second patch where your implementation gets added.
Both make based and meson based build enablement you can add it in that
patch.
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [dpdk-dev] [v2,6/6] doc: add event crypto adapter documentation
2018-04-24 12:43 [dpdk-dev] [v2,0/6] eventdev: cover letter - crypto adapter Abhinandan Gujjar
` (4 preceding siblings ...)
2018-04-24 12:43 ` [dpdk-dev] [v2, 5/6] eventdev: add event crypto adapter to meson build system Abhinandan Gujjar
@ 2018-04-24 12:43 ` Abhinandan Gujjar
2018-04-25 10:31 ` [dpdk-dev] [v2, 6/6] " Kovacevic, Marko
2018-04-29 16:30 ` Jerin Jacob
5 siblings, 2 replies; 29+ messages in thread
From: Abhinandan Gujjar @ 2018-04-24 12:43 UTC (permalink / raw)
To: jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: narender.vangati, abhinandan.gujjar, nikhil.rao, gage.eads
Add entries in the programmer's guide, API index, maintainer's file
and release notes for the event crypto adapter.
Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
---
MAINTAINERS | 7 +
doc/api/doxy-api-index.md | 1 +
doc/guides/prog_guide/event_crypto_adapter.rst | 236 +++++++++++++++++++++++++
doc/guides/prog_guide/index.rst | 1 +
doc/guides/rel_notes/release_18_05.rst | 6 +
5 files changed, 251 insertions(+)
create mode 100644 doc/guides/prog_guide/event_crypto_adapter.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ba316b..f13a4b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -356,6 +356,13 @@ F: lib/librte_eventdev/*timer_adapter*
F: test/test/test_event_timer_adapter.c
F: doc/guides/prog_guide/event_timer_adapter.rst
+Eventdev Crypto Adapter API - EXPERIMENTAL
+M: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
+T: git://dpdk.org/next/dpdk-next-eventdev
+F: lib/librte_eventdev/*crypto_adapter*
+F: test/test/test_event_crypto_adapter.c
+F: doc/guides/prog_guide/event_crypto_adapter.rst
+
Raw device API - EXPERIMENTAL
M: Shreyansh Jain <shreyansh.jain@nxp.com>
M: Hemant Agrawal <hemant.agrawal@nxp.com>
diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
index 26ce7b4..0162bb7 100644
--- a/doc/api/doxy-api-index.md
+++ b/doc/api/doxy-api-index.md
@@ -21,6 +21,7 @@ The public API headers are grouped by topics:
[eventdev] (@ref rte_eventdev.h),
[event_eth_rx_adapter] (@ref rte_event_eth_rx_adapter.h),
[event_timer_adapter] (@ref rte_event_timer_adapter.h),
+ [event_crypto_adapter] (@ref rte_event_crypto_adapter.h),
[rawdev] (@ref rte_rawdev.h),
[metrics] (@ref rte_metrics.h),
[bitrate] (@ref rte_bitrate.h),
diff --git a/doc/guides/prog_guide/event_crypto_adapter.rst b/doc/guides/prog_guide/event_crypto_adapter.rst
new file mode 100644
index 0000000..76d95b3
--- /dev/null
+++ b/doc/guides/prog_guide/event_crypto_adapter.rst
@@ -0,0 +1,236 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright(c) 2018 Intel Corporation.
+
+Event Crypto Adapter Library
+============================
+
+The DPDK Event device library '<http://dpdk.org/doc/guides/prog_guide/eventdev.html>`_
+provides event driven programming model with features to schedule events.
+The cryptodev library '<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_
+provides interface to crypto poll mode drivers which supports different crypto operations.
+The Event Crypto Adapter is one of the event adapter which is intended to bridge between
+event devices and cryptodev.
+
+The packet flow from cryptodev to the event device can be accomplished
+using both SW and HW based transfer mechanisms.
+The Adapter queries an eventdev PMD to determine which mechanism to be used.
+The adapter uses an EAL service core function for SW based packet transfer
+and uses the eventdev PMD functions to configure HW based packet transfer
+between the cryptodev and the event device.
+
+Crypto adapter uses a new event type called ``RTE_EVENT_TYPE_CRYPTODEV``
+to indicate the event source.
+
+API Overview
+------------
+
+This section has a brief introduction to the event crypto adapter APIs.
+The application is expected to create an adapter which is associated with
+a single eventdev, then add cryptodev and queue pair to the adapter instance.
+
+Adapter can be started in ``RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY`` or
+``RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ`` mode.
+In first mode, application will submit a crypto operation directly to cryptodev.
+In the second mode, application will send a crypto ops to cryptodev adapter
+via eventdev. The cryptodev adapter then submits the crypto operation to the
+crypto device.
+
+Create an adapter instance
+--------------------------
+
+An adapter instance is created using ``rte_event_crypto_adapter_create()``. This
+function is called with event device to be associated with the adapter and port
+configuration for the adapter to setup an event port(if the adapter needs to use
+a service function).
+
+.. code-block:: c
+
+ int err;
+ uint8_t dev_id, id;
+ struct rte_event_dev_info dev_info;
+ struct rte_event_port_conf conf;
+ enum rte_event_crypto_adapter_mode mode;
+
+ err = rte_event_dev_info_get(id, &dev_info);
+
+ conf.new_event_threshold = dev_info.max_num_events;
+ conf.dequeue_depth = dev_info.max_event_port_dequeue_depth;
+ conf.enqueue_depth = dev_info.max_event_port_enqueue_depth;
+ mode = RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ;
+ err = rte_event_crypto_adapter_create(id, dev_id, &conf, mode);
+
+If the application desires to have finer control of eventdev port allocation
+and setup, it can use the ``rte_event_crypto_adapter_create_ext()`` function.
+The ``rte_event_crypto_adapter_create_ext()`` function is passed as a callback
+function. The callback function is invoked if the adapter needs to use a
+service function and needs to create an event port for it. The callback is
+expected to fill the ``struct rte_event_crypto_adapter_conf`` structure
+passed to it.
+
+For ENQ-DEQ mode, the event port created by adapter can be retrived using
+``rte_event_crypto_adapter_event_port_get()`` API.
+Application can use this event port to link with event queue on which it
+enqueue events towards the crypto adapter.
+
+.. code-block:: c
+
+ uint8_t id, evdev, crypto_ev_port_id, app_qid;
+ struct rte_event ev;
+ int ret;
+
+ ret = rte_event_crypto_adapter_event_port_get(id, &crypto_ev_port_id);
+ ret = rte_event_queue_setup(evdev, app_qid, NULL);
+ ret = rte_event_port_link(evdev, crypto_ev_port_id, &app_qid, NULL, 1);
+
+ /* Fill in event info and update event_ptr with rte_crypto_op */
+ memset(&ev, 0, sizeof(ev));
+ ev.queue_id = app_qid;
+ .
+ .
+ ev.event_ptr = op;
+ ret = rte_event_enqueue_burst(evdev, app_ev_port_id, ev, nb_events);
+
+
+Adding queue pair to the adapter instance
+-----------------------------------------
+
+Cryptodev device id and queue pair are created using cryptodev APIs.
+Refer '<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_.
+
+.. code-block:: c
+
+ struct rte_cryptodev_config conf;
+ struct rte_cryptodev_qp_conf qp_conf;
+ uint8_t cdev_id = 0;
+ uint16_t qp_id = 0;
+
+ rte_cryptodev_configure(cdev_id, &conf);
+ rte_cryptodev_queue_pair_setup(cdev_id, qp_id, &qp_conf);
+
+These cryptodev id and queue pair are added to the instance using the
+``rte_event_crypto_adapter_queue_pair_add()`` function.
+The same is removed using ``rte_event_crypto_adapter_queue_pair_del()``.
+
+.. code-block:: c
+
+ struct rte_event_crypto_queue_pair_conf conf;
+
+ rte_event_crypto_adapter_queue_pair_add(id, cdev_id, qp_id, &conf);
+
+
+Querying adapter capabilities
+-----------------------------
+
+The ``rte_event_crypto_adapter_caps_get()`` function allows
+the application to query the adapter capabilities for an eventdev and cryptodev
+combination. This API provides whether cryptodev and eventdev are connected using
+internal HW port or not.
+
+.. code-block:: c
+
+ rte_event_crypto_adapter_caps_get(dev_id, cdev_id, &cap);
+
+
+Configure the service function
+------------------------------
+
+If the adapter uses a service function, the application is required to assign
+a service core to the service function as show below.
+
+.. code-block:: c
+
+ uint32_t service_id;
+
+ if (rte_event_crypto_adapter_service_id_get(id, &service_id) == 0)
+ rte_service_map_lcore_set(service_id, CORE_ID);
+
+
+Set event request/response information
+--------------------------------------
+
+In the ENQ_DEQ mode, the application needs to specify the cryptodev ID
+and queue pair ID (request information) in addition to the event
+information (response information) needed to enqueue an event after
+the crypto operation has completed. The request and response information
+are specified in the ``struct rte_crypto_op`` private data or session's
+private data.
+
+In the DEQ mode, the application is required to provide only the
+response information.
+
+The SW adapter or HW PMD uses ``rte_crypto_op::sess_type`` to
+decide whether request/response data is located in the crypto session/
+crypto security session or at an offset in the ``struct rte_crypto_op``.
+The ``rte_crypto_op::private_data_offset`` is used to locate the request/
+response in the ``rte_crypto_op``.
+
+For crypto session, ``rte_cryptodev_sym_session_set_private_data()`` API
+will be used to set request/response data. The same data will be obtained
+by ``rte_cryptodev_sym_session_get_private_data()`` API.
+
+For security session, ``rte_security_session_set_private_data()`` API
+will be used to set request/response data. The same data will be obtained
+by ``rte_security_session_get_private_data()`` API.
+
+For session-less it is mandatory to place the request/response data with
+the ``rte_crypto_op``.
+
+.. code-block:: c
+
+ union rte_event_crypto_metadata m_data;
+ struct rte_event ev;
+ struct rte_crypto_op *op;
+
+ /* Allocate & fill op structure */
+ op = rte_crypto_op_alloc();
+
+ memset(&m_data, 0, sizeof(m_data));
+ memset(&ev, 0, sizeof(ev));
+ /* Fill event information and update event_ptr to rte_crypto_op */
+ ev.event_ptr = op;
+
+ if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
+ /* Copy response information */
+ rte_memcpy(&m_data.response_info, &ev, sizeof(ev));
+ /* Copy request information */
+ m_data.request_info.cdev_id = cdev_id;
+ m_data.request_info.queue_pair_id = qp_id;
+ /* Call set API to store private data information */
+ rte_cryptodev_sym_session_set_private_data(
+ op->sym->session,
+ &m_data,
+ sizeof(m_data));
+ } if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
+ uint32_t len = IV_OFFSET + MAXIMUM_IV_LENGTH +
+ (sizeof(struct rte_crypto_sym_xform) * 2);
+ op->private_data_offset = len;
+ /* Copy response information */
+ rte_memcpy(&m_data.response_info, &ev, sizeof(ev));
+ /* Copy request information */
+ m_data.request_info.cdev_id = cdev_id;
+ m_data.request_info.queue_pair_id = qp_id;
+ /* Store private data information along with rte_crypto_op */
+ rte_memcpy(op + len, &m_data, sizeof(m_data));
+ }
+
+Start the adapter instance
+--------------------------
+
+The application calls ``rte_event_crypto_adapter_start()`` to start the adapter.
+This function calls the start callbacks of the eventdev PMDs for hardware based
+eventdev-cryptodev connections and ``rte_service_run_state_set()`` to enable the
+service function if one exists.
+
+.. code-block:: c
+
+ rte_event_crypto_adapter_start(id, mode);
+
+
+Get adapter statistics
+----------------------
+
+The rte_event_crypto_adapter_stats_get()`` function reports counters defined
+in struct ``rte_event_crypto_adapter_stats``. The received packet and
+enqueued event counts are a sum of the counts from the eventdev PMD callbacks
+if the callback is supported, and the counts maintained by the service function,
+if one exists.
diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
index 589c05d..c2ef87f 100644
--- a/doc/guides/prog_guide/index.rst
+++ b/doc/guides/prog_guide/index.rst
@@ -43,6 +43,7 @@ Programmer's Guide
eventdev
event_ethernet_rx_adapter
event_timer_adapter
+ event_crypto_adapter
qos_framework
power_man
packet_classif_access_ctrl
diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst
index 391a0d4..0ba7013 100644
--- a/doc/guides/rel_notes/release_18_05.rst
+++ b/doc/guides/rel_notes/release_18_05.rst
@@ -77,6 +77,12 @@ New Features
timer expiry events. This new type of event is scheduled by an event device
along with existing types of events.
+* **Added Event Crypto Adapter Library.**
+
+ Added the Event Crypto Adapter Library. This library extends the
+ event-based model by introducing APIs that allow applications to
+ enqueue/dequeue crypto operations to/from cryptodev as events scheduled
+ by an event device.
API Changes
-----------
--
1.9.1
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 6/6] doc: add event crypto adapter documentation
2018-04-24 12:43 ` [dpdk-dev] [v2,6/6] doc: add event crypto adapter documentation Abhinandan Gujjar
@ 2018-04-25 10:31 ` Kovacevic, Marko
2018-04-25 12:15 ` Gujjar, Abhinandan S
2018-04-29 16:30 ` Jerin Jacob
1 sibling, 1 reply; 29+ messages in thread
From: Kovacevic, Marko @ 2018-04-25 10:31 UTC (permalink / raw)
To: Gujjar, Abhinandan S, jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: Vangati, Narender, Gujjar, Abhinandan S, Rao, Nikhil, Eads, Gage
Few things below.
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> MAINTAINERS | 7 +
> doc/api/doxy-api-index.md | 1 +
> doc/guides/prog_guide/event_crypto_adapter.rst | 236
> doc/guides/prog_guide/index.rst | 1 +
> doc/guides/rel_notes/release_18_05.rst | 6 +
> 5 files changed, 251 insertions(+)
> create mode 100644 doc/guides/prog_guide/event_crypto_adapter.rst
<...>
> +Event Crypto Adapter Library
> +============================
> +
> +The DPDK Event device library
> +'<http://dpdk.org/doc/guides/prog_guide/eventdev.html>`_
I'd suggest making a change to the link it looks messy the way it is at the moment
can you link the file this way please,
:doc:`DPDK Event device library <eventdev>`
> +provides event driven programming model with features to schedule
> events.
> +The cryptodev library
> +'<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_
Same above: :doc:`cryptodev library <cryptodev_lib>`
> +provides interface to crypto poll mode drivers which supports different
> crypto operations.
> +The Event Crypto Adapter is one of the event adapter which is intended
> +to bridge between event devices and cryptodev.
<...>
> +The ``rte_event_crypto_adapter_create_ext()`` function is passed as a
> +callback function. The callback function is invoked if the adapter
> +needs to use a service function and needs to create an event port for
> +it. The callback is expected to fill the ``struct
> +rte_event_crypto_adapter_conf`` structure passed to it.
> +
> +For ENQ-DEQ mode, the event port created by adapter can be retrived
Spelling retrived / retrieved
> +using ``rte_event_crypto_adapter_event_port_get()`` API.
> +Application can use this event port to link with event queue on which
> +it enqueue events towards the crypto adapter.
<...>
> +
> +Adding queue pair to the adapter instance
> +-----------------------------------------
> +
> +Cryptodev device id and queue pair are created using cryptodev APIs.
> +Refer '<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_.
Change above:
And maybe instead of just Refer, maybe try "For more information click here"
Just a suggestion
:doc:`here <cryptodev_lib>`.
<...>
> +
> +Get adapter statistics
> +----------------------
> +
> +The rte_event_crypto_adapter_stats_get()`` function reports counters
Missing a `` at the beginning of this function above.
> +defined in struct ``rte_event_crypto_adapter_stats``. The received
> +packet and enqueued event counts are a sum of the counts from the
> +eventdev PMD callbacks if the callback is supported, and the counts
> +maintained by the service function, if one exists.
<...>
Also try and keep the code blocks with 4 to 8 spaces in some cases there is a lot of tabs.
Especially as you have spaces in a few and not others.
Thanks
Marko K.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [dpdk-dev] [v2, 6/6] doc: add event crypto adapter documentation
2018-04-25 10:31 ` [dpdk-dev] [v2, 6/6] " Kovacevic, Marko
@ 2018-04-25 12:15 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-25 12:15 UTC (permalink / raw)
To: Kovacevic, Marko, jerin.jacob, hemant.agrawal, akhil.goyal, dev
Cc: Vangati, Narender, Rao, Nikhil, Eads, Gage
Hi Marko,
Thanks for reviewing.
I will update the below links and also replace tab with 8 spaces for the code blocks.
Regards
Abhinandan
> -----Original Message-----
> From: Kovacevic, Marko
> Sent: Wednesday, April 25, 2018 4:02 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>;
> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com;
> akhil.goyal@nxp.com; dev@dpdk.org
> Cc: Vangati, Narender <narender.vangati@intel.com>; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>; Eads, Gage
> <gage.eads@intel.com>
> Subject: RE: [dpdk-dev] [v2,6/6] doc: add event crypto adapter documentation
>
> Few things below.
>
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > MAINTAINERS | 7 +
> > doc/api/doxy-api-index.md | 1 +
> > doc/guides/prog_guide/event_crypto_adapter.rst | 236
> > doc/guides/prog_guide/index.rst | 1 +
> > doc/guides/rel_notes/release_18_05.rst | 6 +
> > 5 files changed, 251 insertions(+)
> > create mode 100644 doc/guides/prog_guide/event_crypto_adapter.rst
>
> <...>
>
> > +Event Crypto Adapter Library
> > +============================
> > +
> > +The DPDK Event device library
> > +'<http://dpdk.org/doc/guides/prog_guide/eventdev.html>`_
>
> I'd suggest making a change to the link it looks messy the way it is at the
> moment can you link the file this way please,
>
> :doc:`DPDK Event device library <eventdev>`
>
>
> > +provides event driven programming model with features to schedule
> > events.
> > +The cryptodev library
> > +'<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_
>
> Same above: :doc:`cryptodev library <cryptodev_lib>`
>
>
> > +provides interface to crypto poll mode drivers which supports
> > +different
> > crypto operations.
> > +The Event Crypto Adapter is one of the event adapter which is
> > +intended to bridge between event devices and cryptodev.
>
> <...>
>
> > +The ``rte_event_crypto_adapter_create_ext()`` function is passed as a
> > +callback function. The callback function is invoked if the adapter
> > +needs to use a service function and needs to create an event port for
> > +it. The callback is expected to fill the ``struct
> > +rte_event_crypto_adapter_conf`` structure passed to it.
> > +
> > +For ENQ-DEQ mode, the event port created by adapter can be retrived
>
> Spelling retrived / retrieved
>
> > +using ``rte_event_crypto_adapter_event_port_get()`` API.
> > +Application can use this event port to link with event queue on which
> > +it enqueue events towards the crypto adapter.
>
>
> <...>
>
> > +
> > +Adding queue pair to the adapter instance
> > +-----------------------------------------
> > +
> > +Cryptodev device id and queue pair are created using cryptodev APIs.
> > +Refer '<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_.
>
> Change above:
> And maybe instead of just Refer, maybe try "For more information click here"
> Just a suggestion
>
> :doc:`here <cryptodev_lib>`.
>
> <...>
>
> > +
> > +Get adapter statistics
> > +----------------------
> > +
> > +The rte_event_crypto_adapter_stats_get()`` function reports counters
>
> Missing a `` at the beginning of this function above.
>
>
> > +defined in struct ``rte_event_crypto_adapter_stats``. The received
> > +packet and enqueued event counts are a sum of the counts from the
> > +eventdev PMD callbacks if the callback is supported, and the counts
> > +maintained by the service function, if one exists.
>
> <...>
>
> Also try and keep the code blocks with 4 to 8 spaces in some cases there is a lot
> of tabs.
> Especially as you have spaces in a few and not others.
>
> Thanks
>
> Marko K.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [dpdk-dev] [v2, 6/6] doc: add event crypto adapter documentation
2018-04-24 12:43 ` [dpdk-dev] [v2,6/6] doc: add event crypto adapter documentation Abhinandan Gujjar
2018-04-25 10:31 ` [dpdk-dev] [v2, 6/6] " Kovacevic, Marko
@ 2018-04-29 16:30 ` Jerin Jacob
2018-04-30 11:33 ` Gujjar, Abhinandan S
1 sibling, 1 reply; 29+ messages in thread
From: Jerin Jacob @ 2018-04-29 16:30 UTC (permalink / raw)
To: Abhinandan Gujjar
Cc: hemant.agrawal, akhil.goyal, dev, narender.vangati, nikhil.rao,
gage.eads
-----Original Message-----
> Date: Tue, 24 Apr 2018 18:13:27 +0530
> From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> akhil.goyal@nxp.com, dev@dpdk.org
> CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> nikhil.rao@intel.com, gage.eads@intel.com
> Subject: [v2,6/6] doc: add event crypto adapter documentation
> X-Mailer: git-send-email 1.9.1
>
> Add entries in the programmer's guide, API index, maintainer's file
> and release notes for the event crypto adapter.
>
> Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> ---
> +
> +The packet flow from cryptodev to the event device can be accomplished
> +using both SW and HW based transfer mechanisms.
> +The Adapter queries an eventdev PMD to determine which mechanism to be used.
> +The adapter uses an EAL service core function for SW based packet transfer
> +and uses the eventdev PMD functions to configure HW based packet transfer
> +between the cryptodev and the event device.
> +
> +Crypto adapter uses a new event type called ``RTE_EVENT_TYPE_CRYPTODEV``
> +to indicate the event source.
> +
I think, we can add diagrams used in rte_event_crypto_adapter.h with
sequence number in SVG format here to make it easier to understand for the end user.
> +API Overview
> +------------
> +
> +This section has a brief introduction to the event crypto adapter APIs.
> +The application is expected to create an adapter which is associated with
> +a single eventdev, then add cryptodev and queue pair to the adapter instance.
> +
> +Adapter can be started in ``RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY`` or
> +``RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ`` mode.
> +In first mode, application will submit a crypto operation directly to cryptodev.
> +In the second mode, application will send a crypto ops to cryptodev adapter
> +via eventdev. The cryptodev adapter then submits the crypto operation to the
> +crypto device.
> +
> +Create an adapter instance
> +--------------------------
> +
> +An adapter instance is created using ``rte_event_crypto_adapter_create()``. This
> +function is called with event device to be associated with the adapter and port
> +configuration for the adapter to setup an event port(if the adapter needs to use
> +a service function).
> +
> +.. code-block:: c
> +
> + int err;
> + uint8_t dev_id, id;
> + struct rte_event_dev_info dev_info;
> + struct rte_event_port_conf conf;
> + enum rte_event_crypto_adapter_mode mode;
> +
> + err = rte_event_dev_info_get(id, &dev_info);
> +
> + conf.new_event_threshold = dev_info.max_num_events;
> + conf.dequeue_depth = dev_info.max_event_port_dequeue_depth;
> + conf.enqueue_depth = dev_info.max_event_port_enqueue_depth;
> + mode = RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ;
> + err = rte_event_crypto_adapter_create(id, dev_id, &conf, mode);
> +
> +If the application desires to have finer control of eventdev port allocation
> +and setup, it can use the ``rte_event_crypto_adapter_create_ext()`` function.
> +The ``rte_event_crypto_adapter_create_ext()`` function is passed as a callback
> +function. The callback function is invoked if the adapter needs to use a
> +service function and needs to create an event port for it. The callback is
> +expected to fill the ``struct rte_event_crypto_adapter_conf`` structure
> +passed to it.
> +
> +For ENQ-DEQ mode, the event port created by adapter can be retrived using
s/retrived/retrieved ?
> +``rte_event_crypto_adapter_event_port_get()`` API.
> +Application can use this event port to link with event queue on which it
> +enqueue events towards the crypto adapter.
> +
> +.. code-block:: c
> +
> + uint8_t id, evdev, crypto_ev_port_id, app_qid;
> + struct rte_event ev;
> + int ret;
> +
> + ret = rte_event_crypto_adapter_event_port_get(id, &crypto_ev_port_id);
> + ret = rte_event_queue_setup(evdev, app_qid, NULL);
> + ret = rte_event_port_link(evdev, crypto_ev_port_id, &app_qid, NULL, 1);
> +
> + /* Fill in event info and update event_ptr with rte_crypto_op */
> + memset(&ev, 0, sizeof(ev));
> + ev.queue_id = app_qid;
> + .
> + .
> + ev.event_ptr = op;
> + ret = rte_event_enqueue_burst(evdev, app_ev_port_id, ev, nb_events);
> +
> +
> +Adding queue pair to the adapter instance
> +-----------------------------------------
> +
> +Cryptodev device id and queue pair are created using cryptodev APIs.
> +Refer '<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_.
> +
> +.. code-block:: c
> +
> + struct rte_cryptodev_config conf;
> + struct rte_cryptodev_qp_conf qp_conf;
> + uint8_t cdev_id = 0;
> + uint16_t qp_id = 0;
> +
> + rte_cryptodev_configure(cdev_id, &conf);
> + rte_cryptodev_queue_pair_setup(cdev_id, qp_id, &qp_conf);
> +
> +These cryptodev id and queue pair are added to the instance using the
> +``rte_event_crypto_adapter_queue_pair_add()`` function.
> +The same is removed using ``rte_event_crypto_adapter_queue_pair_del()``.
> +
> +.. code-block:: c
> +
> + struct rte_event_crypto_queue_pair_conf conf;
> +
> + rte_event_crypto_adapter_queue_pair_add(id, cdev_id, qp_id, &conf);
> +
> +
> +Querying adapter capabilities
> +-----------------------------
> +
> +The ``rte_event_crypto_adapter_caps_get()`` function allows
> +the application to query the adapter capabilities for an eventdev and cryptodev
> +combination. This API provides whether cryptodev and eventdev are connected using
> +internal HW port or not.
> +
> +.. code-block:: c
> +
> + rte_event_crypto_adapter_caps_get(dev_id, cdev_id, &cap);
> +
> +
> +Configure the service function
> +------------------------------
> +
> +If the adapter uses a service function, the application is required to assign
> +a service core to the service function as show below.
> +
> +.. code-block:: c
> +
> + uint32_t service_id;
> +
> + if (rte_event_crypto_adapter_service_id_get(id, &service_id) == 0)
> + rte_service_map_lcore_set(service_id, CORE_ID);
> +
> +
> +Set event request/response information
> +--------------------------------------
> +
> +In the ENQ_DEQ mode, the application needs to specify the cryptodev ID
> +and queue pair ID (request information) in addition to the event
> +information (response information) needed to enqueue an event after
> +the crypto operation has completed. The request and response information
> +are specified in the ``struct rte_crypto_op`` private data or session's
> +private data.
I think, we can mention the use of rte_event_crypto_adapter_event_port_get()
API here.
> +
> +In the DEQ mode, the application is required to provide only the
> +response information.
> +
> +The SW adapter or HW PMD uses ``rte_crypto_op::sess_type`` to
> +decide whether request/response data is located in the crypto session/
> +crypto security session or at an offset in the ``struct rte_crypto_op``.
> +The ``rte_crypto_op::private_data_offset`` is used to locate the request/
> +response in the ``rte_crypto_op``.
> +
> +For crypto session, ``rte_cryptodev_sym_session_set_private_data()`` API
> +will be used to set request/response data. The same data will be obtained
> +by ``rte_cryptodev_sym_session_get_private_data()`` API.
> +
> +For security session, ``rte_security_session_set_private_data()`` API
> +will be used to set request/response data. The same data will be obtained
> +by ``rte_security_session_get_private_data()`` API.
I think, we need to talk about RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
capability here and have check in sample code/common code(please ignore
if the check is already present in common code)
> +
> +For session-less it is mandatory to place the request/response data with
> +the ``rte_crypto_op``.
> +
> +.. code-block:: c
> +
> + union rte_event_crypto_metadata m_data;
> + struct rte_event ev;
> + struct rte_crypto_op *op;
> +
> + /* Allocate & fill op structure */
> + op = rte_crypto_op_alloc();
> +
> + memset(&m_data, 0, sizeof(m_data));
> + memset(&ev, 0, sizeof(ev));
> + /* Fill event information and update event_ptr to rte_crypto_op */
> + ev.event_ptr = op;
> +
> + if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> + /* Copy response information */
> + rte_memcpy(&m_data.response_info, &ev, sizeof(ev));
> + /* Copy request information */
> + m_data.request_info.cdev_id = cdev_id;
> + m_data.request_info.queue_pair_id = qp_id;
> + /* Call set API to store private data information */
> + rte_cryptodev_sym_session_set_private_data(
> + op->sym->session,
> + &m_data,
> + sizeof(m_data));
> + } if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
> + uint32_t len = IV_OFFSET + MAXIMUM_IV_LENGTH +
> + (sizeof(struct rte_crypto_sym_xform) * 2);
> + op->private_data_offset = len;
> + /* Copy response information */
> + rte_memcpy(&m_data.response_info, &ev, sizeof(ev));
> + /* Copy request information */
> + m_data.request_info.cdev_id = cdev_id;
> + m_data.request_info.queue_pair_id = qp_id;
> + /* Store private data information along with rte_crypto_op */
> + rte_memcpy(op + len, &m_data, sizeof(m_data));
> + }
> +
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [dpdk-dev] [v2, 6/6] doc: add event crypto adapter documentation
2018-04-29 16:30 ` Jerin Jacob
@ 2018-04-30 11:33 ` Gujjar, Abhinandan S
0 siblings, 0 replies; 29+ messages in thread
From: Gujjar, Abhinandan S @ 2018-04-30 11:33 UTC (permalink / raw)
To: Jerin Jacob
Cc: hemant.agrawal, akhil.goyal, dev, Vangati, Narender, Rao, Nikhil,
Eads, Gage
> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Sunday, April 29, 2018 10:01 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati,
> Narender <narender.vangati@intel.com>; Rao, Nikhil <nikhil.rao@intel.com>;
> Eads, Gage <gage.eads@intel.com>
> Subject: Re: [v2,6/6] doc: add event crypto adapter documentation
>
> -----Original Message-----
> > Date: Tue, 24 Apr 2018 18:13:27 +0530
> > From: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com,
> > akhil.goyal@nxp.com, dev@dpdk.org
> > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com,
> > nikhil.rao@intel.com, gage.eads@intel.com
> > Subject: [v2,6/6] doc: add event crypto adapter documentation
> > X-Mailer: git-send-email 1.9.1
> >
> > Add entries in the programmer's guide, API index, maintainer's file
> > and release notes for the event crypto adapter.
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> > +
> > +The packet flow from cryptodev to the event device can be
> > +accomplished using both SW and HW based transfer mechanisms.
> > +The Adapter queries an eventdev PMD to determine which mechanism to be
> used.
> > +The adapter uses an EAL service core function for SW based packet
> > +transfer and uses the eventdev PMD functions to configure HW based
> > +packet transfer between the cryptodev and the event device.
> > +
> > +Crypto adapter uses a new event type called
> > +``RTE_EVENT_TYPE_CRYPTODEV`` to indicate the event source.
> > +
>
> I think, we can add diagrams used in rte_event_crypto_adapter.h with sequence
> number in SVG format here to make it easier to understand for the end user.
Sure
>
>
> > +API Overview
> > +------------
> > +
> > +This section has a brief introduction to the event crypto adapter APIs.
> > +The application is expected to create an adapter which is associated
> > +with a single eventdev, then add cryptodev and queue pair to the adapter
> instance.
> > +
> > +Adapter can be started in ``RTE_EVENT_CRYPTO_ADAPTER_DEQ_ONLY`` or
> > +``RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ`` mode.
> > +In first mode, application will submit a crypto operation directly to cryptodev.
> > +In the second mode, application will send a crypto ops to cryptodev
> > +adapter via eventdev. The cryptodev adapter then submits the crypto
> > +operation to the crypto device.
> > +
> > +Create an adapter instance
> > +--------------------------
> > +
> > +An adapter instance is created using
> > +``rte_event_crypto_adapter_create()``. This function is called with
> > +event device to be associated with the adapter and port configuration
> > +for the adapter to setup an event port(if the adapter needs to use a service
> function).
> > +
> > +.. code-block:: c
> > +
> > + int err;
> > + uint8_t dev_id, id;
> > + struct rte_event_dev_info dev_info;
> > + struct rte_event_port_conf conf;
> > + enum rte_event_crypto_adapter_mode mode;
> > +
> > + err = rte_event_dev_info_get(id, &dev_info);
> > +
> > + conf.new_event_threshold = dev_info.max_num_events;
> > + conf.dequeue_depth = dev_info.max_event_port_dequeue_depth;
> > + conf.enqueue_depth = dev_info.max_event_port_enqueue_depth;
> > + mode = RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ;
> > + err = rte_event_crypto_adapter_create(id, dev_id, &conf,
> > +mode);
> > +
> > +If the application desires to have finer control of eventdev port
> > +allocation and setup, it can use the
> ``rte_event_crypto_adapter_create_ext()`` function.
> > +The ``rte_event_crypto_adapter_create_ext()`` function is passed as a
> > +callback function. The callback function is invoked if the adapter
> > +needs to use a service function and needs to create an event port for
> > +it. The callback is expected to fill the ``struct
> > +rte_event_crypto_adapter_conf`` structure passed to it.
> > +
> > +For ENQ-DEQ mode, the event port created by adapter can be retrived
> > +using
>
> s/retrived/retrieved ?
Ok
>
> > +``rte_event_crypto_adapter_event_port_get()`` API.
> > +Application can use this event port to link with event queue on which
> > +it enqueue events towards the crypto adapter.
> > +
> > +.. code-block:: c
> > +
> > + uint8_t id, evdev, crypto_ev_port_id, app_qid;
> > + struct rte_event ev;
> > + int ret;
> > +
> > + ret = rte_event_crypto_adapter_event_port_get(id,
> &crypto_ev_port_id);
> > + ret = rte_event_queue_setup(evdev, app_qid, NULL);
> > + ret = rte_event_port_link(evdev, crypto_ev_port_id, &app_qid, NULL,
> > +1);
> > +
> > + /* Fill in event info and update event_ptr with rte_crypto_op */
> > + memset(&ev, 0, sizeof(ev));
> > + ev.queue_id = app_qid;
> > + .
> > + .
> > + ev.event_ptr = op;
> > + ret = rte_event_enqueue_burst(evdev, app_ev_port_id, ev, nb_events);
> > +
> > +
> > +Adding queue pair to the adapter instance
> > +-----------------------------------------
> > +
> > +Cryptodev device id and queue pair are created using cryptodev APIs.
> > +Refer '<http://dpdk.org/doc/guides/prog_guide/cryptodev_lib.html>`_.
> > +
> > +.. code-block:: c
> > +
> > + struct rte_cryptodev_config conf;
> > + struct rte_cryptodev_qp_conf qp_conf;
> > + uint8_t cdev_id = 0;
> > + uint16_t qp_id = 0;
> > +
> > + rte_cryptodev_configure(cdev_id, &conf);
> > + rte_cryptodev_queue_pair_setup(cdev_id, qp_id, &qp_conf);
> > +
> > +These cryptodev id and queue pair are added to the instance using the
> > +``rte_event_crypto_adapter_queue_pair_add()`` function.
> > +The same is removed using ``rte_event_crypto_adapter_queue_pair_del()``.
> > +
> > +.. code-block:: c
> > +
> > + struct rte_event_crypto_queue_pair_conf conf;
> > +
> > + rte_event_crypto_adapter_queue_pair_add(id, cdev_id, qp_id, &conf);
> > +
> > +
> > +Querying adapter capabilities
> > +-----------------------------
> > +
> > +The ``rte_event_crypto_adapter_caps_get()`` function allows the
> > +application to query the adapter capabilities for an eventdev and
> > +cryptodev combination. This API provides whether cryptodev and
> > +eventdev are connected using internal HW port or not.
> > +
> > +.. code-block:: c
> > +
> > + rte_event_crypto_adapter_caps_get(dev_id, cdev_id, &cap);
> > +
> > +
> > +Configure the service function
> > +------------------------------
> > +
> > +If the adapter uses a service function, the application is required
> > +to assign a service core to the service function as show below.
> > +
> > +.. code-block:: c
> > +
> > + uint32_t service_id;
> > +
> > + if (rte_event_crypto_adapter_service_id_get(id, &service_id) == 0)
> > + rte_service_map_lcore_set(service_id, CORE_ID);
> > +
> > +
> > +Set event request/response information
> > +--------------------------------------
> > +
> > +In the ENQ_DEQ mode, the application needs to specify the cryptodev
> > +ID and queue pair ID (request information) in addition to the event
> > +information (response information) needed to enqueue an event after
> > +the crypto operation has completed. The request and response
> > +information are specified in the ``struct rte_crypto_op`` private
> > +data or session's private data.
>
> I think, we can mention the use of rte_event_crypto_adapter_event_port_get()
> API here.
I have added a para and a code block for this above.
>
> > +
> > +In the DEQ mode, the application is required to provide only the
> > +response information.
> > +
> > +The SW adapter or HW PMD uses ``rte_crypto_op::sess_type`` to decide
> > +whether request/response data is located in the crypto session/
> > +crypto security session or at an offset in the ``struct rte_crypto_op``.
> > +The ``rte_crypto_op::private_data_offset`` is used to locate the
> > +request/ response in the ``rte_crypto_op``.
> > +
> > +For crypto session, ``rte_cryptodev_sym_session_set_private_data()``
> > +API will be used to set request/response data. The same data will be
> > +obtained by ``rte_cryptodev_sym_session_get_private_data()`` API.
> > +
> > +For security session, ``rte_security_session_set_private_data()`` API
> > +will be used to set request/response data. The same data will be
> > +obtained by ``rte_security_session_get_private_data()`` API.
>
> I think, we need to talk about
> RTE_EVENT_CRYPTO_ADAPTER_CAP_SESSION_PRIVATE_DATA
> capability here and have check in sample code/common code(please ignore if
> the check is already present in common code)
Ok
>
> > +
> > +For session-less it is mandatory to place the request/response data
> > +with the ``rte_crypto_op``.
> > +
> > +.. code-block:: c
> > +
> > + union rte_event_crypto_metadata m_data;
> > + struct rte_event ev;
> > + struct rte_crypto_op *op;
> > +
> > + /* Allocate & fill op structure */
> > + op = rte_crypto_op_alloc();
> > +
> > + memset(&m_data, 0, sizeof(m_data));
> > + memset(&ev, 0, sizeof(ev));
> > + /* Fill event information and update event_ptr to rte_crypto_op */
> > + ev.event_ptr = op;
> > +
> > + if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> > + /* Copy response information */
> > + rte_memcpy(&m_data.response_info, &ev, sizeof(ev));
> > + /* Copy request information */
> > + m_data.request_info.cdev_id = cdev_id;
> > + m_data.request_info.queue_pair_id = qp_id;
> > + /* Call set API to store private data information */
> > + rte_cryptodev_sym_session_set_private_data(
> > + op->sym->session,
> > + &m_data,
> > + sizeof(m_data));
> > + } if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
> > + uint32_t len = IV_OFFSET + MAXIMUM_IV_LENGTH +
> > + (sizeof(struct rte_crypto_sym_xform) * 2);
> > + op->private_data_offset = len;
> > + /* Copy response information */
> > + rte_memcpy(&m_data.response_info, &ev, sizeof(ev));
> > + /* Copy request information */
> > + m_data.request_info.cdev_id = cdev_id;
> > + m_data.request_info.queue_pair_id = qp_id;
> > + /* Store private data information along with rte_crypto_op */
> > + rte_memcpy(op + len, &m_data, sizeof(m_data));
> > + }
> > +
^ permalink raw reply [flat|nested] 29+ messages in thread