[dpdk-dev] [v6 0/2] support enqueue & dequeue callbacks on cryptodev

[dpdk-dev] [v6 0/2] support enqueue & dequeue callbacks on cryptodev

[Abhinandan Gujjar]

In an eventdev world, multiple workers (with ordered queue) will be
working on IPsec ESP processing. The ESP header's sequence number is
unique and has to be sequentially incremented in an orderly manner.
This rises a need for incrementing sequence number in crypto stage
especially in event crypto adapter. By adding a user callback to
cryptodev at enqueue burst, the user callback will get executed
in the context of event crypto adapter. This helps the application
to increment the ESP sequence number atomically and orderly manner.
The user callback at the dequeue burst helps IPsec application to
take care of ARW processing.

v5->v6:
    -Removed error code in remove callback APIs & cb init
    -Updated release notes & documentation

v4->v5:
    -Added dequeue callback APIs
    -Updated documentation
    -Updated errno and return values
    -Updated cleanup function

v3->v4:
    -Move callback init and cleanup under dev_configure
    -Update with memory ordering
    -Removed extra level of indirection
    -Add documentation

v2->v3:
    -Moved RCU under the cryptodev APIs
    -RCU is maintained per queue-pair
    -Changed name of few variables
    -Updated callback test with negative cases
    -Updated with required changes for meson

v1->v2:
    -Moved callback related members to the end of cryptodev struct
    -Added support for RCU

Abhinandan Gujjar (2):
  cryptodev: support enqueue & dequeue callback functions
  test: add testcase for crypto enqueue callback

 app/test/test_cryptodev.c               | 135 ++++++++++-
 config/rte_config.h                     |   1 +
 doc/guides/prog_guide/cryptodev_lib.rst |  47 ++++
 doc/guides/rel_notes/release_20_11.rst  |   9 +
 lib/librte_cryptodev/meson.build        |   2 +-
 lib/librte_cryptodev/rte_cryptodev.c    | 404 +++++++++++++++++++++++++++++++-
 lib/librte_cryptodev/rte_cryptodev.h    | 260 +++++++++++++++++++-
 lib/librte_cryptodev/version.map        |   4 +
 8 files changed, 857 insertions(+), 5 deletions(-)

-- 
1.9.1

[dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Abhinandan Gujjar]

This patch adds APIs to add/remove callback functions on crypto
enqueue/dequeue burst. The callback function will be called for
each burst of crypto ops received/sent on a given crypto device
queue pair.

Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 config/rte_config.h                     |   1 +
 doc/guides/prog_guide/cryptodev_lib.rst |  47 ++++
 doc/guides/rel_notes/release_20_11.rst  |   9 +
 lib/librte_cryptodev/meson.build        |   2 +-
 lib/librte_cryptodev/rte_cryptodev.c    | 404 +++++++++++++++++++++++++++++++-
 lib/librte_cryptodev/rte_cryptodev.h    | 260 +++++++++++++++++++-
 lib/librte_cryptodev/version.map        |   4 +
 7 files changed, 724 insertions(+), 3 deletions(-)

diff --git a/config/rte_config.h b/config/rte_config.h
index 8aa46a1..0e3ddbb 100644
--- a/config/rte_config.h
+++ b/config/rte_config.h
@@ -62,6 +62,7 @@
 /* cryptodev defines */
 #define RTE_CRYPTO_MAX_DEVS 64
 #define RTE_CRYPTODEV_NAME_LEN 64
+#define RTE_CRYPTO_CALLBACKS 1
 
 /* compressdev defines */
 #define RTE_COMPRESS_MAX_DEVS 64
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 72129e4..9d0ff59 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -338,6 +338,53 @@ start of private data information. The offset is counted from the start of the
 rte_crypto_op including other crypto information such as the IVs (since there can
 be an IV also for authentication).
 
+User callback APIs
+~~~~~~~~~~~~~~~~~~
+The add APIs configures a user callback function to be called for each burst of crypto
+ops received/sent on a given crypto device queue pair. The return value is a pointer
+that can be used later to remove the callback API. Application is expected to register
+a callback function of type ``rte_cryptodev_callback_fn``. Multiple callback functions
+can be added for a given queue pair. API does not restrict on maximum number of
+callbacks.
+
+Callbacks registered by application would not survive rte_cryptodev_configure() as it
+reinitializes the callback list. It is user responsibility to remove all installed
+callbacks before calling rte_cryptodev_configure() to avoid possible memory leakage.
+
+So, application is expected to add user callback after rte_cryptodev_configure().
+The callbacks can also be added at the runtime. These callbacks get executed when
+``rte_cryptodev_enqueue_burst``/``rte_cryptodev_dequeue_burst`` is called.
+
+.. code-block:: c
+
+   struct rte_cryptodev_cb *
+	rte_cryptodev_add_enq_callback(uint8_t dev_id,
+				       uint16_t qp_id,
+				       rte_cryptodev_callback_fn cb_fn,
+				       void *cb_arg);
+
+   struct rte_cryptodev_cb *
+	rte_cryptodev_add_deq_callback(uint8_t dev_id,
+				       uint16_t qp_id,
+				       rte_cryptodev_callback_fn cb_fn,
+				       void *cb_arg);
+
+	uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
+		struct rte_crypto_op **ops, uint16_t nb_ops, void *user_param);
+
+The remove API removes a callback function added by
+``rte_cryptodev_add_enq_callback``/``rte_cryptodev_add_deq_callback''.
+
+.. code-block:: c
+
+	int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+					      uint16_t qp_id,
+				              struct rte_cryptodev_cb *cb);
+
+	int rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+					      uint16_t qp_id,
+				              struct rte_cryptodev_cb *cb);
+
 
 Enqueue / Dequeue Burst APIs
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_20_11.rst b/doc/guides/rel_notes/release_20_11.rst
index bae39b2..33e190a 100644
--- a/doc/guides/rel_notes/release_20_11.rst
+++ b/doc/guides/rel_notes/release_20_11.rst
@@ -235,6 +235,12 @@ New Features
   enqueue/dequeue operations but does not necessarily depends on
   mbufs and cryptodev operation mempools.
 
+* **Added enqueue & dequeue callback APIs for cryptodev library.**
+
+  Cryptodev library is added with enqueue & dequeue callback APIs to
+  enable applications to add/remove user callbacks which gets called
+  for every enqueue/dequeue operation.
+
 * **Updated the aesni_mb crypto PMD.**
 
   * Added support for AES-ECB 128, 192 and 256.
@@ -492,6 +498,9 @@ API Changes
   ``RTE_CRYPTO_AUTH_LIST_END`` from ``enum rte_crypto_auth_algorithm``
   are removed to avoid future ABI breakage while adding new algorithms.
 
+* cryptodev: The structure ``rte_cryptodev`` has been updated with pointers
+  for adding enqueue and dequeue callbacks.
+
 * scheduler: Renamed functions ``rte_cryptodev_scheduler_slave_attach``,
   ``rte_cryptodev_scheduler_slave_detach`` and
   ``rte_cryptodev_scheduler_slaves_get`` to
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index c4c6b3b..8c5493f 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -9,4 +9,4 @@ headers = files('rte_cryptodev.h',
 	'rte_crypto.h',
 	'rte_crypto_sym.h',
 	'rte_crypto_asym.h')
-deps += ['kvargs', 'mbuf']
+deps += ['kvargs', 'mbuf', 'rcu']
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 3d95ac6..eb8c832 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -448,6 +448,124 @@ struct rte_cryptodev_sym_session_pool_private_data {
 	return 0;
 }
 
+#ifdef RTE_CRYPTO_CALLBACKS
+/* spinlock for crypto device enq callbacks */
+static rte_spinlock_t rte_cryptodev_callback_lock = RTE_SPINLOCK_INITIALIZER;
+
+static void
+cryptodev_cb_cleanup(struct rte_cryptodev *dev)
+{
+	struct rte_cryptodev_cb_rcu *list;
+	struct rte_cryptodev_cb *cb, *next;
+	uint16_t qp_id;
+
+	if (dev->enq_cbs == NULL && dev->deq_cbs == NULL)
+		return;
+
+	for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+		list = &dev->enq_cbs[qp_id];
+		cb = list->next;
+		while (cb != NULL) {
+			next = cb->next;
+			rte_free(cb);
+			cb = next;
+		}
+
+		rte_free(list->qsbr);
+	}
+
+	for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+		list = &dev->deq_cbs[qp_id];
+		cb = list->next;
+		while (cb != NULL) {
+			next = cb->next;
+			rte_free(cb);
+			cb = next;
+		}
+
+		rte_free(list->qsbr);
+	}
+
+	rte_free(dev->enq_cbs);
+	dev->enq_cbs = NULL;
+	rte_free(dev->deq_cbs);
+	dev->deq_cbs = NULL;
+}
+
+static int
+cryptodev_cb_init(struct rte_cryptodev *dev)
+{
+	struct rte_cryptodev_cb_rcu *list;
+	struct rte_rcu_qsbr *qsbr;
+	uint16_t qp_id;
+	size_t size;
+
+	/* Max thread set to 1, as one DP thread accessing a queue-pair */
+	const uint32_t max_threads = 1;
+
+	dev->enq_cbs = rte_zmalloc(NULL,
+				   sizeof(struct rte_cryptodev_cb_rcu) *
+				   dev->data->nb_queue_pairs, 0);
+	if (dev->enq_cbs == NULL) {
+		CDEV_LOG_ERR("Failed to allocate memory for enq callbacks");
+		return -ENOMEM;
+	}
+
+	dev->deq_cbs = rte_zmalloc(NULL,
+				   sizeof(struct rte_cryptodev_cb_rcu) *
+				   dev->data->nb_queue_pairs, 0);
+	if (dev->deq_cbs == NULL) {
+		CDEV_LOG_ERR("Failed to allocate memory for deq callbacks");
+		rte_free(dev->enq_cbs);
+		return -ENOMEM;
+	}
+
+	/* Create RCU QSBR variable */
+	size = rte_rcu_qsbr_get_memsize(max_threads);
+
+	for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+		list = &dev->enq_cbs[qp_id];
+		qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
+		if (qsbr == NULL) {
+			CDEV_LOG_ERR("Failed to allocate memory for RCU on "
+				"queue_pair_id=%d", qp_id);
+			goto cb_init_err;
+		}
+
+		if (rte_rcu_qsbr_init(qsbr, max_threads)) {
+			CDEV_LOG_ERR("Failed to initialize for RCU on "
+				"queue_pair_id=%d", qp_id);
+			goto cb_init_err;
+		}
+
+		list->qsbr = qsbr;
+	}
+
+	for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
+		list = &dev->deq_cbs[qp_id];
+		qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
+		if (qsbr == NULL) {
+			CDEV_LOG_ERR("Failed to allocate memory for RCU on "
+				"queue_pair_id=%d", qp_id);
+			goto cb_init_err;
+		}
+
+		if (rte_rcu_qsbr_init(qsbr, max_threads)) {
+			CDEV_LOG_ERR("Failed to initialize for RCU on "
+				"queue_pair_id=%d", qp_id);
+			goto cb_init_err;
+		}
+
+		list->qsbr = qsbr;
+	}
+
+	return 0;
+
+cb_init_err:
+	cryptodev_cb_cleanup(dev);
+	return -ENOMEM;
+}
+#endif
 
 const char *
 rte_cryptodev_get_feature_name(uint64_t flag)
@@ -927,6 +1045,11 @@ struct rte_cryptodev *
 
 	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_configure, -ENOTSUP);
 
+#ifdef RTE_CRYPTO_CALLBACKS
+	rte_spinlock_lock(&rte_cryptodev_callback_lock);
+	cryptodev_cb_cleanup(dev);
+	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+#endif
 	/* Setup new number of queue pairs and reconfigure device. */
 	diag = rte_cryptodev_queue_pairs_config(dev, config->nb_queue_pairs,
 			config->socket_id);
@@ -936,11 +1059,19 @@ struct rte_cryptodev *
 		return diag;
 	}
 
+#ifdef RTE_CRYPTO_CALLBACKS
+	rte_spinlock_lock(&rte_cryptodev_callback_lock);
+	diag = cryptodev_cb_init(dev);
+	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+	if (diag) {
+		CDEV_LOG_ERR("Callback init failed for dev_id=%d", dev_id);
+		return diag;
+	}
+#endif
 	rte_cryptodev_trace_configure(dev_id, config);
 	return (*dev->dev_ops->dev_configure)(dev, config);
 }
 
-
 int
 rte_cryptodev_start(uint8_t dev_id)
 {
@@ -1136,6 +1267,277 @@ struct rte_cryptodev *
 			socket_id);
 }
 
+#ifdef RTE_CRYPTO_CALLBACKS
+struct rte_cryptodev_cb *
+rte_cryptodev_add_enq_callback(uint8_t dev_id,
+			       uint16_t qp_id,
+			       rte_cryptodev_callback_fn cb_fn,
+			       void *cb_arg)
+{
+	struct rte_cryptodev *dev;
+	struct rte_cryptodev_cb_rcu *list;
+	struct rte_cryptodev_cb *cb, *tail;
+
+	if (!cb_fn) {
+		CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
+		rte_errno = EINVAL;
+		return NULL;
+	}
+
+	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+		rte_errno = ENODEV;
+		return NULL;
+	}
+
+	dev = &rte_crypto_devices[dev_id];
+	if (qp_id >= dev->data->nb_queue_pairs) {
+		CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+		rte_errno = ENODEV;
+		return NULL;
+	}
+
+	cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+	if (cb == NULL) {
+		CDEV_LOG_ERR("Failed to allocate memory for callback on "
+			     "dev=%d, queue_pair_id=%d", dev_id, qp_id);
+		rte_errno = ENOMEM;
+		return NULL;
+	}
+
+	rte_spinlock_lock(&rte_cryptodev_callback_lock);
+
+	cb->fn = cb_fn;
+	cb->arg = cb_arg;
+
+	/* Add the callbacks in fifo order. */
+	list = &dev->enq_cbs[qp_id];
+	tail = list->next;
+
+	if (tail) {
+		while (tail->next)
+			tail = tail->next;
+		/* Stores to cb->fn and cb->param should complete before
+		 * cb is visible to data plane.
+		 */
+		__atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
+	} else {
+		/* Stores to cb->fn and cb->param should complete before
+		 * cb is visible to data plane.
+		 */
+		__atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
+	}
+
+	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
+	return cb;
+}
+
+int
+rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+				  uint16_t qp_id,
+				  struct rte_cryptodev_cb *cb)
+{
+	struct rte_cryptodev *dev;
+	struct rte_cryptodev_cb **prev_cb, *curr_cb;
+	struct rte_cryptodev_cb_rcu *list;
+	int ret;
+
+	ret = -EINVAL;
+
+	if (!cb) {
+		CDEV_LOG_ERR("Callback is NULL");
+		return -EINVAL;
+	}
+
+	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+		return -ENODEV;
+	}
+
+	dev = &rte_crypto_devices[dev_id];
+	if (qp_id >= dev->data->nb_queue_pairs) {
+		CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+		return -ENODEV;
+	}
+
+	rte_spinlock_lock(&rte_cryptodev_callback_lock);
+	if (dev->enq_cbs == NULL) {
+		CDEV_LOG_ERR("Callback not initialized");
+		goto cb_err;
+	}
+
+	list = &dev->enq_cbs[qp_id];
+	if (list == NULL) {
+		CDEV_LOG_ERR("Callback list is NULL");
+		goto cb_err;
+	}
+
+	if (list->qsbr == NULL) {
+		CDEV_LOG_ERR("Rcu qsbr is NULL");
+		goto cb_err;
+	}
+
+	prev_cb = &list->next;
+	for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
+		curr_cb = *prev_cb;
+		if (curr_cb == cb) {
+			/* Remove the user cb from the callback list. */
+			__atomic_store_n(prev_cb, curr_cb->next,
+				__ATOMIC_RELAXED);
+			ret = 0;
+			break;
+		}
+	}
+
+	if (!ret) {
+		/* Call sync with invalid thread id as this is part of
+		 * control plane API
+		 */
+		rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
+		rte_free(cb);
+	}
+
+cb_err:
+	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+	return ret;
+}
+
+struct rte_cryptodev_cb *
+rte_cryptodev_add_deq_callback(uint8_t dev_id,
+			       uint16_t qp_id,
+			       rte_cryptodev_callback_fn cb_fn,
+			       void *cb_arg)
+{
+	struct rte_cryptodev *dev;
+	struct rte_cryptodev_cb_rcu *list;
+	struct rte_cryptodev_cb *cb, *tail;
+
+	if (!cb_fn) {
+		CDEV_LOG_ERR("Callback is NULL on dev_id=%d", dev_id);
+		rte_errno = EINVAL;
+		return NULL;
+	}
+
+	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+		rte_errno = ENODEV;
+		return NULL;
+	}
+
+	dev = &rte_crypto_devices[dev_id];
+	if (qp_id >= dev->data->nb_queue_pairs) {
+		CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+		rte_errno = ENODEV;
+		return NULL;
+	}
+
+	cb = rte_zmalloc(NULL, sizeof(*cb), 0);
+	if (cb == NULL) {
+		CDEV_LOG_ERR("Failed to allocate memory for callback on "
+			     "dev=%d, queue_pair_id=%d", dev_id, qp_id);
+		rte_errno = ENOMEM;
+		return NULL;
+	}
+
+	rte_spinlock_lock(&rte_cryptodev_callback_lock);
+
+	cb->fn = cb_fn;
+	cb->arg = cb_arg;
+
+	/* Add the callbacks in fifo order. */
+	list = &dev->deq_cbs[qp_id];
+	tail = list->next;
+
+	if (tail) {
+		while (tail->next)
+			tail = tail->next;
+		/* Stores to cb->fn and cb->param should complete before
+		 * cb is visible to data plane.
+		 */
+		__atomic_store_n(&tail->next, cb, __ATOMIC_RELEASE);
+	} else {
+		/* Stores to cb->fn and cb->param should complete before
+		 * cb is visible to data plane.
+		 */
+		__atomic_store_n(&list->next, cb, __ATOMIC_RELEASE);
+	}
+
+	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+
+	return cb;
+}
+
+int
+rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+				  uint16_t qp_id,
+				  struct rte_cryptodev_cb *cb)
+{
+	struct rte_cryptodev *dev;
+	struct rte_cryptodev_cb **prev_cb, *curr_cb;
+	struct rte_cryptodev_cb_rcu *list;
+	int ret;
+
+	ret = -EINVAL;
+
+	if (!cb) {
+		CDEV_LOG_ERR("Callback is NULL");
+		return -EINVAL;
+	}
+
+	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+		return -ENODEV;
+	}
+
+	dev = &rte_crypto_devices[dev_id];
+	if (qp_id >= dev->data->nb_queue_pairs) {
+		CDEV_LOG_ERR("Invalid queue_pair_id=%d", qp_id);
+		return -ENODEV;
+	}
+
+	rte_spinlock_lock(&rte_cryptodev_callback_lock);
+	if (dev->enq_cbs == NULL) {
+		CDEV_LOG_ERR("Callback not initialized");
+		goto cb_err;
+	}
+
+	list = &dev->deq_cbs[qp_id];
+	if (list == NULL) {
+		CDEV_LOG_ERR("Callback list is NULL");
+		goto cb_err;
+	}
+
+	if (list->qsbr == NULL) {
+		CDEV_LOG_ERR("Rcu qsbr is NULL");
+		goto cb_err;
+	}
+
+	prev_cb = &list->next;
+	for (; *prev_cb != NULL; prev_cb = &curr_cb->next) {
+		curr_cb = *prev_cb;
+		if (curr_cb == cb) {
+			/* Remove the user cb from the callback list. */
+			__atomic_store_n(prev_cb, curr_cb->next,
+				__ATOMIC_RELAXED);
+			ret = 0;
+			break;
+		}
+	}
+
+	if (!ret) {
+		/* Call sync with invalid thread id as this is part of
+		 * control plane API
+		 */
+		rte_rcu_qsbr_synchronize(list->qsbr, RTE_QSBR_THRID_INVALID);
+		rte_free(cb);
+	}
+
+cb_err:
+	rte_spinlock_unlock(&rte_cryptodev_callback_lock);
+	return ret;
+}
+#endif
 
 int
 rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 0935fd5..e6ab755 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -23,6 +23,7 @@
 #include "rte_dev.h"
 #include <rte_common.h>
 #include <rte_config.h>
+#include <rte_rcu_qsbr.h>
 
 #include "rte_cryptodev_trace_fp.h"
 
@@ -522,6 +523,32 @@ struct rte_cryptodev_qp_conf {
 	/**< The mempool for creating sess private data in sessionless mode */
 };
 
+#ifdef RTE_CRYPTO_CALLBACKS
+/**
+ * Function type used for processing crypto ops when enqueue/dequeue burst is
+ * called.
+ *
+ * The callback function is called on enqueue/dequeue burst immediately.
+ *
+ * @param	dev_id		The identifier of the device.
+ * @param	qp_id		The index of the queue pair on which ops are
+ *				enqueued/dequeued. The value must be in the
+ *				range [0, nb_queue_pairs - 1] previously
+ *				supplied to *rte_cryptodev_configure*.
+ * @param	ops		The address of an array of *nb_ops* pointers
+ *				to *rte_crypto_op* structures which contain
+ *				the crypto operations to be processed.
+ * @param	nb_ops		The number of operations to process.
+ * @param	user_param	The arbitrary user parameter passed in by the
+ *				application when the callback was originally
+ *				registered.
+ * @return			The number of ops to be enqueued to the
+ *				crypto device.
+ */
+typedef uint16_t (*rte_cryptodev_callback_fn)(uint16_t dev_id, uint16_t qp_id,
+		struct rte_crypto_op **ops, uint16_t nb_ops, void *user_param);
+#endif
+
 /**
  * Typedef for application callback function to be registered by application
  * software for notification of device events
@@ -822,7 +849,6 @@ struct rte_cryptodev_config {
 		enum rte_cryptodev_event_type event,
 		rte_cryptodev_cb_fn cb_fn, void *cb_arg);
 
-
 typedef uint16_t (*dequeue_pkt_burst_t)(void *qp,
 		struct rte_crypto_op **ops,	uint16_t nb_ops);
 /**< Dequeue processed packets from queue pair of a device. */
@@ -839,6 +865,33 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
 /** Structure to keep track of registered callbacks */
 TAILQ_HEAD(rte_cryptodev_cb_list, rte_cryptodev_callback);
 
+#ifdef RTE_CRYPTO_CALLBACKS
+/**
+ * @internal
+ * Structure used to hold information about the callbacks to be called for a
+ * queue pair on enqueue/dequeue.
+ */
+struct rte_cryptodev_cb {
+	struct rte_cryptodev_cb *next;
+	/** < Pointer to next callback */
+	rte_cryptodev_callback_fn fn;
+	/** < Pointer to callback function */
+	void *arg;
+	/** < Pointer to argument */
+};
+
+/**
+ * @internal
+ * Structure used to hold information about the RCU for a queue pair.
+ */
+struct rte_cryptodev_cb_rcu {
+	struct rte_cryptodev_cb *next;
+	/** < Pointer to next callback */
+	struct rte_rcu_qsbr *qsbr;
+	/** < RCU QSBR variable per queue pair */
+};
+#endif
+
 /** The data structure associated with each crypto device. */
 struct rte_cryptodev {
 	dequeue_pkt_burst_t dequeue_burst;
@@ -867,6 +920,12 @@ struct rte_cryptodev {
 	__extension__
 	uint8_t attached : 1;
 	/**< Flag indicating the device is attached */
+
+	struct rte_cryptodev_cb_rcu *enq_cbs;
+	/**< User application callback for pre enqueue processing */
+
+	struct rte_cryptodev_cb_rcu *deq_cbs;
+	/**< User application callback for post dequeue processing */
 } __rte_cache_aligned;
 
 void *
@@ -945,6 +1004,30 @@ struct rte_cryptodev_data {
 {
 	struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
 
+#ifdef RTE_CRYPTO_CALLBACKS
+	if (unlikely(dev->deq_cbs != NULL)) {
+		struct rte_cryptodev_cb_rcu *list;
+		struct rte_cryptodev_cb *cb;
+
+		/* __ATOMIC_RELEASE memory order was used when the
+		 * call back was inserted into the list.
+		 * Since there is a clear dependency between loading
+		 * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+		 * not required.
+		 */
+		list = &dev->deq_cbs[qp_id];
+		rte_rcu_qsbr_thread_online(list->qsbr, 0);
+		cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
+
+		while (cb != NULL) {
+			nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
+					cb->arg);
+			cb = cb->next;
+		};
+
+		rte_rcu_qsbr_thread_offline(list->qsbr, 0);
+	}
+#endif
 	nb_ops = (*dev->dequeue_burst)
 			(dev->data->queue_pairs[qp_id], ops, nb_ops);
 
@@ -989,6 +1072,31 @@ struct rte_cryptodev_data {
 {
 	struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
 
+#ifdef RTE_CRYPTO_CALLBACKS
+	if (unlikely(dev->enq_cbs != NULL)) {
+		struct rte_cryptodev_cb_rcu *list;
+		struct rte_cryptodev_cb *cb;
+
+		/* __ATOMIC_RELEASE memory order was used when the
+		 * call back was inserted into the list.
+		 * Since there is a clear dependency between loading
+		 * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+		 * not required.
+		 */
+		list = &dev->enq_cbs[qp_id];
+		rte_rcu_qsbr_thread_online(list->qsbr, 0);
+		cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
+
+		while (cb != NULL) {
+			nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
+					cb->arg);
+			cb = cb->next;
+		};
+
+		rte_rcu_qsbr_thread_offline(list->qsbr, 0);
+	}
+#endif
+
 	rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, nb_ops);
 	return (*dev->enqueue_burst)(
 			dev->data->queue_pairs[qp_id], ops, nb_ops);
@@ -1730,6 +1838,156 @@ struct rte_crypto_raw_dp_ctx {
 rte_cryptodev_raw_dequeue_done(struct rte_crypto_raw_dp_ctx *ctx,
 		uint32_t n);
 
+#ifdef RTE_CRYPTO_CALLBACKS
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Add a user callback for a given crypto device and queue pair which will be
+ * called on crypto ops enqueue.
+ *
+ * This API configures a function to be called for each burst of crypto ops
+ * received on a given crypto device queue pair. The return value is a pointer
+ * that can be used later to remove the callback using
+ * rte_cryptodev_remove_enq_callback().
+ *
+ * Callbacks registered by application would not survive
+ * rte_cryptodev_configure() as it reinitializes the callback list.
+ * It is user responsibility to remove all installed callbacks before
+ * calling rte_cryptodev_configure() to avoid possible memory leakage.
+ * Application is expected to call add API after rte_cryptodev_configure().
+ *
+ * Multiple functions can be registered per queue pair & they are called
+ * in the order they were added. The API does not restrict on maximum number
+ * of callbacks.
+ *
+ * @param	dev_id		The identifier of the device.
+ * @param	qp_id		The index of the queue pair on which ops are
+ *				to be enqueued for processing. The value
+ *				must be in the range [0, nb_queue_pairs - 1]
+ *				previously supplied to
+ *				*rte_cryptodev_configure*.
+ * @param	cb_fn		The callback function
+ * @param	cb_arg		A generic pointer parameter which will be passed
+ *				to each invocation of the callback function on
+ *				this crypto device and queue pair.
+ *
+ * @return
+ *   NULL on error & rte_errno will contain the error code.
+ *   On success, a pointer value which can later be used to remove the callback.
+ */
+
+__rte_experimental
+struct rte_cryptodev_cb *
+rte_cryptodev_add_enq_callback(uint8_t dev_id,
+			       uint16_t qp_id,
+			       rte_cryptodev_callback_fn cb_fn,
+			       void *cb_arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Remove a user callback function for given crypto device and queue pair.
+ *
+ * This function is used to remove enqueue callbacks that were added to a
+ * crypto device queue pair using rte_cryptodev_add_enq_callback().
+ *
+ *
+ *
+ * @param	dev_id		The identifier of the device.
+ * @param	qp_id		The index of the queue pair on which ops are
+ *				to be enqueued. The value must be in the
+ *				range [0, nb_queue_pairs - 1] previously
+ *				supplied to *rte_cryptodev_configure*.
+ * @param	cb		Pointer to user supplied callback created via
+ *				rte_cryptodev_add_enq_callback().
+ *
+ * @return
+ *   -  0: Success. Callback was removed.
+ *   - <0: The dev_id or the qp_id is out of range, or the callback
+ *         is NULL or not found for the crypto device queue pair.
+ */
+
+__rte_experimental
+int rte_cryptodev_remove_enq_callback(uint8_t dev_id,
+				      uint16_t qp_id,
+				      struct rte_cryptodev_cb *cb);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Add a user callback for a given crypto device and queue pair which will be
+ * called on crypto ops dequeue.
+ *
+ * This API configures a function to be called for each burst of crypto ops
+ * received on a given crypto device queue pair. The return value is a pointer
+ * that can be used later to remove the callback using
+ * rte_cryptodev_remove_deq_callback().
+ *
+ * Callbacks registered by application would not survive
+ * rte_cryptodev_configure() as it reinitializes the callback list.
+ * It is user responsibility to remove all installed callbacks before
+ * calling rte_cryptodev_configure() to avoid possible memory leakage.
+ * Application is expected to call add API after rte_cryptodev_configure().
+ *
+ * Multiple functions can be registered per queue pair & they are called
+ * in the order they were added. The API does not restrict on maximum number
+ * of callbacks.
+ *
+ * @param	dev_id		The identifier of the device.
+ * @param	qp_id		The index of the queue pair on which ops are
+ *				to be dequeued. The value must be in the
+ *				range [0, nb_queue_pairs - 1] previously
+ *				supplied to *rte_cryptodev_configure*.
+ * @param	cb_fn		The callback function
+ * @param	cb_arg		A generic pointer parameter which will be passed
+ *				to each invocation of the callback function on
+ *				this crypto device and queue pair.
+ *
+ * @return
+ *   NULL on error & rte_errno will contain the error code.
+ *   On success, a pointer value which can later be used to remove the callback.
+ */
+
+__rte_experimental
+struct rte_cryptodev_cb *
+rte_cryptodev_add_deq_callback(uint8_t dev_id,
+			       uint16_t qp_id,
+			       rte_cryptodev_callback_fn cb_fn,
+			       void *cb_arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Remove a user callback function for given crypto device and queue pair.
+ *
+ * This function is used to remove dequeue callbacks that were added to a
+ * crypto device queue pair using rte_cryptodev_add_deq_callback().
+ *
+ *
+ *
+ * @param	dev_id		The identifier of the device.
+ * @param	qp_id		The index of the queue pair on which ops are
+ *				to be dequeued. The value must be in the
+ *				range [0, nb_queue_pairs - 1] previously
+ *				supplied to *rte_cryptodev_configure*.
+ * @param	cb		Pointer to user supplied callback created via
+ *				rte_cryptodev_add_deq_callback().
+ *
+ * @return
+ *   -  0: Success. Callback was removed.
+ *   - <0: The dev_id or the qp_id is out of range, or the callback
+ *         is NULL or not found for the crypto device queue pair.
+ */
+__rte_experimental
+int rte_cryptodev_remove_deq_callback(uint8_t dev_id,
+				      uint16_t qp_id,
+				      struct rte_cryptodev_cb *cb);
+#endif
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_cryptodev/version.map b/lib/librte_cryptodev/version.map
index 7e4360f..429b03e 100644
--- a/lib/librte_cryptodev/version.map
+++ b/lib/librte_cryptodev/version.map
@@ -101,6 +101,8 @@ EXPERIMENTAL {
 	rte_cryptodev_get_qp_status;
 
 	# added in 20.11
+	rte_cryptodev_add_deq_callback;
+	rte_cryptodev_add_enq_callback;
 	rte_cryptodev_configure_raw_dp_ctx;
 	rte_cryptodev_get_raw_dp_ctx_size;
 	rte_cryptodev_raw_dequeue;
@@ -109,4 +111,6 @@ EXPERIMENTAL {
 	rte_cryptodev_raw_enqueue;
 	rte_cryptodev_raw_enqueue_burst;
 	rte_cryptodev_raw_enqueue_done;
+	rte_cryptodev_remove_deq_callback;
+	rte_cryptodev_remove_enq_callback;
 };
-- 
1.9.1

[dpdk-dev] [v6 2/2] test: add testcase for crypto enqueue callback

[Abhinandan Gujjar]

This patch adds test case for testing functionality of
enqueue callback mechanism.

Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
 app/test/test_cryptodev.c | 135 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 133 insertions(+), 2 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 2128b01..ada7838 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -10728,6 +10728,135 @@ struct multi_session_params {
 	return TEST_SUCCESS;
 }
 
+#ifdef RTE_CRYPTO_CALLBACKS
+static uint16_t
+test_enq_callback(uint16_t dev_id, uint16_t qp_id, struct rte_crypto_op **ops,
+		  uint16_t nb_ops, void *user_param)
+{
+	RTE_SET_USED(dev_id);
+	RTE_SET_USED(qp_id);
+	RTE_SET_USED(ops);
+	RTE_SET_USED(user_param);
+
+	printf("crypto enqueue callback called\n");
+	return nb_ops;
+}
+
+/*
+ * Thread using enqueue callback with RCU.
+ */
+static int
+test_enq_callback_rcu_thread(void *arg)
+{
+	RTE_SET_USED(arg);
+	/* DP thread calls rte_cryptodev_enqueue_burst() and
+	 * invokes enqueue callback.
+	 */
+	test_null_burst_operation();
+	return 0;
+}
+
+static int
+test_enq_callback_setup(void)
+{
+	struct crypto_testsuite_params *ts_params = &testsuite_params;
+	struct rte_cryptodev_info dev_info;
+	struct rte_cryptodev_qp_conf qp_conf = {
+		.nb_descriptors = MAX_NUM_OPS_INFLIGHT
+	};
+
+	struct rte_cryptodev_cb *cb;
+	uint16_t qp_id = 0;
+
+	/* Stop the device in case it's started so it can be configured */
+	rte_cryptodev_stop(ts_params->valid_devs[0]);
+
+	rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
+
+	TEST_ASSERT_SUCCESS(rte_cryptodev_configure(ts_params->valid_devs[0],
+			&ts_params->conf),
+			"Failed to configure cryptodev %u",
+			ts_params->valid_devs[0]);
+
+	qp_conf.nb_descriptors = MAX_NUM_OPS_INFLIGHT;
+	qp_conf.mp_session = ts_params->session_mpool;
+	qp_conf.mp_session_private = ts_params->session_priv_mpool;
+
+	TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
+			ts_params->valid_devs[0], qp_id, &qp_conf,
+			rte_cryptodev_socket_id(ts_params->valid_devs[0])),
+			"Failed test for "
+			"rte_cryptodev_queue_pair_setup: num_inflights "
+			"%u on qp %u on cryptodev %u",
+			qp_conf.nb_descriptors, qp_id,
+			ts_params->valid_devs[0]);
+
+	/* Test with invalid crypto device */
+	cb = rte_cryptodev_add_enq_callback(RTE_CRYPTO_MAX_DEVS,
+			qp_id, test_enq_callback, NULL);
+	TEST_ASSERT_NULL(cb, "Add callback on qp %u on "
+			"cryptodev %u did not fail",
+			qp_id, RTE_CRYPTO_MAX_DEVS);
+
+	/* Test with invalid queue pair */
+	cb = rte_cryptodev_add_enq_callback(ts_params->valid_devs[0],
+			dev_info.max_nb_queue_pairs + 1,
+			test_enq_callback, NULL);
+	TEST_ASSERT_NULL(cb, "Add callback on qp %u on "
+			"cryptodev %u did not fail",
+			dev_info.max_nb_queue_pairs + 1,
+			ts_params->valid_devs[0]);
+
+	/* Test with NULL callback */
+	cb = rte_cryptodev_add_enq_callback(ts_params->valid_devs[0],
+			qp_id, NULL, NULL);
+	TEST_ASSERT_NULL(cb, "Add callback on qp %u on "
+			"cryptodev %u did not fail",
+			qp_id, ts_params->valid_devs[0]);
+
+	/* Test with valid configuration */
+	cb = rte_cryptodev_add_enq_callback(ts_params->valid_devs[0],
+			qp_id, test_enq_callback, NULL);
+	TEST_ASSERT_NOT_NULL(cb, "Failed test to add callback on "
+			"qp %u on cryptodev %u",
+			qp_id, ts_params->valid_devs[0]);
+
+	rte_cryptodev_start(ts_params->valid_devs[0]);
+
+	/* Launch a thread */
+	rte_eal_remote_launch(test_enq_callback_rcu_thread, NULL,
+				rte_get_next_lcore(-1, 1, 0));
+
+	/* Wait until reader exited. */
+	rte_eal_mp_wait_lcore();
+
+	/* Test with invalid crypto device */
+	TEST_ASSERT_FAIL(rte_cryptodev_remove_enq_callback(
+			RTE_CRYPTO_MAX_DEVS, qp_id, cb),
+			"Expected call to fail as crypto device is invalid");
+
+	/* Test with invalid queue pair */
+	TEST_ASSERT_FAIL(rte_cryptodev_remove_enq_callback(
+			ts_params->valid_devs[0],
+			dev_info.max_nb_queue_pairs + 1, cb),
+			"Expected call to fail as queue pair is invalid");
+
+	/* Test with NULL callback */
+	TEST_ASSERT_FAIL(rte_cryptodev_remove_enq_callback(
+			ts_params->valid_devs[0], qp_id, NULL),
+			"Expected call to fail as callback is NULL");
+
+	/* Test with valid configuration */
+	TEST_ASSERT_SUCCESS(rte_cryptodev_remove_enq_callback(
+			ts_params->valid_devs[0], qp_id, cb),
+			"Failed test to remove callback on "
+			"qp %u on cryptodev %u",
+			qp_id, ts_params->valid_devs[0]);
+
+	return TEST_SUCCESS;
+}
+#endif
+
 static void
 generate_gmac_large_plaintext(uint8_t *data)
 {
@@ -13048,7 +13177,6 @@ struct test_crypto_vector {
 				test_queue_pair_descriptor_setup),
 		TEST_CASE_ST(ut_setup, ut_teardown,
 				test_device_configure_invalid_queue_pair_ids),
-
 		TEST_CASE_ST(ut_setup, ut_teardown,
 				test_multi_session),
 		TEST_CASE_ST(ut_setup, ut_teardown,
@@ -13057,7 +13185,6 @@ struct test_crypto_vector {
 		TEST_CASE_ST(ut_setup, ut_teardown,
 			test_null_invalid_operation),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_null_burst_operation),
-
 		TEST_CASE_ST(ut_setup, ut_teardown, test_AES_chain_all),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_AES_cipheronly_all),
 		TEST_CASE_ST(ut_setup, ut_teardown, test_3DES_chain_all),
@@ -13671,6 +13798,10 @@ struct test_crypto_vector {
 		TEST_CASE_ST(ut_setup_security, ut_teardown,
 			test_DOCSIS_PROTO_all),
 #endif
+
+#ifdef RTE_CRYPTO_CALLBACKS
+		TEST_CASE_ST(ut_setup, ut_teardown, test_enq_callback_setup),
+#endif
 		TEST_CASES_END() /**< NULL terminate unit test array */
 	}
 };
-- 
1.9.1

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Akhil Goyal]

Hi Abhinandan,

> +struct rte_cryptodev_cb {
> +	struct rte_cryptodev_cb *next;
> +	/** < Pointer to next callback */
> +	rte_cryptodev_callback_fn fn;
> +	/** < Pointer to callback function */
> +	void *arg;
> +	/** < Pointer to argument */
> +};
> +
> +/**
> + * @internal
> + * Structure used to hold information about the RCU for a queue pair.
> + */
> +struct rte_cryptodev_cb_rcu {
> +	struct rte_cryptodev_cb *next;
> +	/** < Pointer to next callback */
> +	struct rte_rcu_qsbr *qsbr;
> +	/** < RCU QSBR variable per queue pair */
> +};
> +#endif
There is an extra space in each of the comments above between * and <.
Check other doxygen errors if any.

I believe the timestamp in your system is not correct, as the patchwork show
Date of 2 days back while the patches are sent today.
Could you please check? I believe CI server is not picking your patches for auto build.
Please correct it so that auto build can happen. None of your version was picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Gujjar, Abhinandan S]

Hi Akhil,

Regarding the date, I am not sure how it can be fixed now.
May be the space is missed out as well. Could be please help?

Regards
Abhinandan


> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Friday, October 30, 2020 11:59 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback functions
> 
> Hi Abhinandan,
> 
> > +struct rte_cryptodev_cb {
> > +	struct rte_cryptodev_cb *next;
> > +	/** < Pointer to next callback */
> > +	rte_cryptodev_callback_fn fn;
> > +	/** < Pointer to callback function */
> > +	void *arg;
> > +	/** < Pointer to argument */
> > +};
> > +
> > +/**
> > + * @internal
> > + * Structure used to hold information about the RCU for a queue pair.
> > + */
> > +struct rte_cryptodev_cb_rcu {
> > +	struct rte_cryptodev_cb *next;
> > +	/** < Pointer to next callback */
> > +	struct rte_rcu_qsbr *qsbr;
> > +	/** < RCU QSBR variable per queue pair */ }; #endif
> There is an extra space in each of the comments above between * and <.
> Check other doxygen errors if any.
> 
> I believe the timestamp in your system is not correct, as the patchwork show
> Date of 2 days back while the patches are sent today.
> Could you please check? I believe CI server is not picking your patches for auto
> build.
> Please correct it so that auto build can happen. None of your version was
> picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Gujjar, Abhinandan S]

Hi Akhil,

What is the status of this patch? Is it pulled into RC2?

Regards
Abhinandan

> -----Original Message-----
> From: Gujjar, Abhinandan S
> Sent: Saturday, October 31, 2020 12:06 AM
> To: 'Akhil Goyal' <akhil.goyal@nxp.com>; dev@dpdk.org; Doherty, Declan
> <declan.doherty@intel.com>; Honnappa.Nagarahalli@arm.com; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback functions
> 
> Hi Akhil,
> 
> Regarding the date, I am not sure how it can be fixed now.
> May be the space is missed out as well. Could be please help?
> 
> Regards
> Abhinandan
> 
> 
> > -----Original Message-----
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > Sent: Friday, October 30, 2020 11:59 PM
> > To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Doherty, Declan <declan.doherty@intel.com>;
> > Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>
> > Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> > Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback
> > functions
> >
> > Hi Abhinandan,
> >
> > > +struct rte_cryptodev_cb {
> > > +	struct rte_cryptodev_cb *next;
> > > +	/** < Pointer to next callback */
> > > +	rte_cryptodev_callback_fn fn;
> > > +	/** < Pointer to callback function */
> > > +	void *arg;
> > > +	/** < Pointer to argument */
> > > +};
> > > +
> > > +/**
> > > + * @internal
> > > + * Structure used to hold information about the RCU for a queue pair.
> > > + */
> > > +struct rte_cryptodev_cb_rcu {
> > > +	struct rte_cryptodev_cb *next;
> > > +	/** < Pointer to next callback */
> > > +	struct rte_rcu_qsbr *qsbr;
> > > +	/** < RCU QSBR variable per queue pair */ }; #endif
> > There is an extra space in each of the comments above between * and <.
> > Check other doxygen errors if any.
> >
> > I believe the timestamp in your system is not correct, as the
> > patchwork show Date of 2 days back while the patches are sent today.
> > Could you please check? I believe CI server is not picking your
> > patches for auto build.
> > Please correct it so that auto build can happen. None of your version
> > was picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Akhil Goyal]

Hi Abhinandan,

> Hi Akhil,
> 
> What is the status of this patch? Is it pulled into RC2?
> 
> 
As I suggested below, please fix your date and let the CI pick your patches for build.
In my local build for documentation, the newly added APIs are not added in the
Documentation. Please fix doxygen issues as soon as possible.
Did you try building documentation at your end?

Regards,
Akhil

> >
> > Regarding the date, I am not sure how it can be fixed now.
> > May be the space is missed out as well. Could be please help?
> >
> > >
> > > > +struct rte_cryptodev_cb {
> > > > +	struct rte_cryptodev_cb *next;
> > > > +	/** < Pointer to next callback */
> > > > +	rte_cryptodev_callback_fn fn;
> > > > +	/** < Pointer to callback function */
> > > > +	void *arg;
> > > > +	/** < Pointer to argument */
> > > > +};
> > > > +
> > > > +/**
> > > > + * @internal
> > > > + * Structure used to hold information about the RCU for a queue pair.
> > > > + */
> > > > +struct rte_cryptodev_cb_rcu {
> > > > +	struct rte_cryptodev_cb *next;
> > > > +	/** < Pointer to next callback */
> > > > +	struct rte_rcu_qsbr *qsbr;
> > > > +	/** < RCU QSBR variable per queue pair */ }; #endif
> > > There is an extra space in each of the comments above between * and <.
> > > Check other doxygen errors if any.
> > >
> > > I believe the timestamp in your system is not correct, as the
> > > patchwork show Date of 2 days back while the patches are sent today.
> > > Could you please check? I believe CI server is not picking your
> > > patches for auto build.
> > > Please correct it so that auto build can happen. None of your version
> > > was picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Gujjar, Abhinandan S]

Hi Akhil,

Can you please go through the patch again and check if any more comments?
I understand that we work in same time zone, getting feedback from you in the mid night will not help me/you to pull this patch in.
A quick response will enable me to prepare patch set quickly and send it across.

This time, I will prepare the patch along with dequeue test case.
Hope you understand the concern. Thanks..

Regards
Abhinandan
   

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, November 3, 2020 12:28 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback functions
> 
> Hi Abhinandan,
> 
> > Hi Akhil,
> >
> > What is the status of this patch? Is it pulled into RC2?
> >
> >
> As I suggested below, please fix your date and let the CI pick your patches for
> build.
> In my local build for documentation, the newly added APIs are not added in the
> Documentation. Please fix doxygen issues as soon as possible.
> Did you try building documentation at your end?
> 
> Regards,
> Akhil
> 
> > >
> > > Regarding the date, I am not sure how it can be fixed now.
> > > May be the space is missed out as well. Could be please help?
> > >
> > > >
> > > > > +struct rte_cryptodev_cb {
> > > > > +	struct rte_cryptodev_cb *next;
> > > > > +	/** < Pointer to next callback */
> > > > > +	rte_cryptodev_callback_fn fn;
> > > > > +	/** < Pointer to callback function */
> > > > > +	void *arg;
> > > > > +	/** < Pointer to argument */
> > > > > +};
> > > > > +
> > > > > +/**
> > > > > + * @internal
> > > > > + * Structure used to hold information about the RCU for a queue pair.
> > > > > + */
> > > > > +struct rte_cryptodev_cb_rcu {
> > > > > +	struct rte_cryptodev_cb *next;
> > > > > +	/** < Pointer to next callback */
> > > > > +	struct rte_rcu_qsbr *qsbr;
> > > > > +	/** < RCU QSBR variable per queue pair */ }; #endif
> > > > There is an extra space in each of the comments above between * and <.
> > > > Check other doxygen errors if any.
> > > >
> > > > I believe the timestamp in your system is not correct, as the
> > > > patchwork show Date of 2 days back while the patches are sent today.
> > > > Could you please check? I believe CI server is not picking your
> > > > patches for auto build.
> > > > Please correct it so that auto build can happen. None of your
> > > > version was picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Akhil Goyal]

Hi Abhinandan,
> Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback functions
> 
> Hi Akhil,
> 
> Can you please go through the patch again and check if any more comments?

As I suggested 2 times that there are documentation issues. Haven't seen a version
To fix that. Please check it at your end and try fixing the timing of your system so that CI
Can pick it for compilation.

> I understand that we work in same time zone, getting feedback from you in the
> mid night will not help me/you to pull this patch in.
> A quick response will enable me to prepare patch set quickly and send it across.

I am not dedicatedly working on your patchset. I will work as per my priorities.
Had it been a CI pass for compilation for both documentation and code,
it would have been applied last night. I could remove those extra spaces,
but there are other issues also as the newly added APIs are not visible in html
files generated. Please ensure that there are no issues in doxygen build issues and
should be able to see the newly added APIs in html guides.

And please note, do not top post your comments. It becomes difficult to read it in
Archives.

> 
> This time, I will prepare the patch along with dequeue test case.
> Hope you understand the concern. Thanks..
> 
> >
> > Hi Abhinandan,
> >
> > > Hi Akhil,
> > >
> > > What is the status of this patch? Is it pulled into RC2?
> > >
> > >
> > As I suggested below, please fix your date and let the CI pick your patches for
> > build.
> > In my local build for documentation, the newly added APIs are not added in the
> > Documentation. Please fix doxygen issues as soon as possible.
> > Did you try building documentation at your end?
> >
> > Regards,
> > Akhil
> >
> > > >
> > > > Regarding the date, I am not sure how it can be fixed now.
> > > > May be the space is missed out as well. Could be please help?
> > > >
> > > > >
> > > > > > +struct rte_cryptodev_cb {
> > > > > > +	struct rte_cryptodev_cb *next;
> > > > > > +	/** < Pointer to next callback */
> > > > > > +	rte_cryptodev_callback_fn fn;
> > > > > > +	/** < Pointer to callback function */
> > > > > > +	void *arg;
> > > > > > +	/** < Pointer to argument */
> > > > > > +};
> > > > > > +
> > > > > > +/**
> > > > > > + * @internal
> > > > > > + * Structure used to hold information about the RCU for a queue pair.
> > > > > > + */
> > > > > > +struct rte_cryptodev_cb_rcu {
> > > > > > +	struct rte_cryptodev_cb *next;
> > > > > > +	/** < Pointer to next callback */
> > > > > > +	struct rte_rcu_qsbr *qsbr;
> > > > > > +	/** < RCU QSBR variable per queue pair */ }; #endif
> > > > > There is an extra space in each of the comments above between * and <.
> > > > > Check other doxygen errors if any.
> > > > >
> > > > > I believe the timestamp in your system is not correct, as the
> > > > > patchwork show Date of 2 days back while the patches are sent today.
> > > > > Could you please check? I believe CI server is not picking your
> > > > > patches for auto build.
> > > > > Please correct it so that auto build can happen. None of your
> > > > > version was picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Gujjar, Abhinandan S]

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, November 3, 2020 11:58 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback functions
> 
> Hi Abhinandan,
> > Subject: RE: [v6 1/2] cryptodev: support enqueue & dequeue callback
> > functions
> >
> > Hi Akhil,
> >
> > Can you please go through the patch again and check if any more comments?
> 
> As I suggested 2 times that there are documentation issues. Haven't seen a
> version To fix that. Please check it at your end and try fixing the timing of your
> system so that CI Can pick it for compilation.
As far as I remember, I have pulled in all the comments from you for the previous patch.
> 
> > I understand that we work in same time zone, getting feedback from you
> > in the mid night will not help me/you to pull this patch in.
> > A quick response will enable me to prepare patch set quickly and send it
> across.
> 
> I am not dedicatedly working on your patchset. I will work as per my priorities.
It is same for me. End of the day, we have mutually agreed to get this feature in.

> Had it been a CI pass for compilation for both documentation and code, it
> would have been applied last night. I could remove those extra spaces, but
> there are other issues also as the newly added APIs are not visible in html files
> generated. Please ensure that there are no issues in doxygen build issues and
> should be able to see the newly added APIs in html guides.
This is the kind of information I was looking for, which was not available in your
previous patch. If this info had been available quickly, I would have prepared next patchset.
Anyway, I will post the next patch set.
> 
> And please note, do not top post your comments. It becomes difficult to read it
> in Archives.
Ok
> 
> >
> > This time, I will prepare the patch along with dequeue test case.
> > Hope you understand the concern. Thanks..
> >
> > >
> > > Hi Abhinandan,
> > >
> > > > Hi Akhil,
> > > >
> > > > What is the status of this patch? Is it pulled into RC2?
> > > >
> > > >
> > > As I suggested below, please fix your date and let the CI pick your
> > > patches for build.
> > > In my local build for documentation, the newly added APIs are not
> > > added in the Documentation. Please fix doxygen issues as soon as possible.
> > > Did you try building documentation at your end?
> > >
> > > Regards,
> > > Akhil
> > >
> > > > >
> > > > > Regarding the date, I am not sure how it can be fixed now.
> > > > > May be the space is missed out as well. Could be please help?
> > > > >
> > > > > >
> > > > > > > +struct rte_cryptodev_cb {
> > > > > > > +	struct rte_cryptodev_cb *next;
> > > > > > > +	/** < Pointer to next callback */
> > > > > > > +	rte_cryptodev_callback_fn fn;
> > > > > > > +	/** < Pointer to callback function */
> > > > > > > +	void *arg;
> > > > > > > +	/** < Pointer to argument */ };
> > > > > > > +
> > > > > > > +/**
> > > > > > > + * @internal
> > > > > > > + * Structure used to hold information about the RCU for a queue
> pair.
> > > > > > > + */
> > > > > > > +struct rte_cryptodev_cb_rcu {
> > > > > > > +	struct rte_cryptodev_cb *next;
> > > > > > > +	/** < Pointer to next callback */
> > > > > > > +	struct rte_rcu_qsbr *qsbr;
> > > > > > > +	/** < RCU QSBR variable per queue pair */ }; #endif
> > > > > > There is an extra space in each of the comments above between * and
> <.
> > > > > > Check other doxygen errors if any.
> > > > > >
> > > > > > I believe the timestamp in your system is not correct, as the
> > > > > > patchwork show Date of 2 days back while the patches are sent today.
> > > > > > Could you please check? I believe CI server is not picking
> > > > > > your patches for auto build.
> > > > > > Please correct it so that auto build can happen. None of your
> > > > > > version was picked by CI.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Thomas Monjalon]

03/11/2020 08:44, Gujjar, Abhinandan S:
> From: Akhil Goyal <akhil.goyal@nxp.com>
> > As I suggested 2 times that there are documentation issues. Haven't seen a
> > version To fix that. Please check it at your end and try fixing the timing of your
> > system so that CI Can pick it for compilation.
> 
> As far as I remember, I have pulled in all the comments from you for the previous patch.
> > 
> > > I understand that we work in same time zone, getting feedback from you
> > > in the mid night will not help me/you to pull this patch in.
> > > A quick response will enable me to prepare patch set quickly and send it
> > across.
> > 
> > I am not dedicatedly working on your patchset. I will work as per my priorities.
>
> It is same for me. End of the day, we have mutually agreed to get this feature in.
> 
> > Had it been a CI pass for compilation for both documentation and code, it
> > would have been applied last night. I could remove those extra spaces, but
> > there are other issues also as the newly added APIs are not visible in html files
> > generated. Please ensure that there are no issues in doxygen build issues and
> > should be able to see the newly added APIs in html guides.
> 
> This is the kind of information I was looking for, which was not available in your
> previous patch. If this info had been available quickly, I would have prepared next patchset.

It seems you didn't do all the checks you are required to do.
Please be kind with Akhil who is working hard for the community.
If you want to accelerate the process, help by reviewing other patches.

> Anyway, I will post the next patch set.

This is too late.
We are not supposed to add new API in -rc2,
and for sure not after -rc2 deadline.

> > 
> > And please note, do not top post your comments. It becomes difficult to read it
> > in Archives.
> 
> Ok

Yes please do not top post, use --in-reply-to to gather all versions
in the same thread, and fix the clock of your machine.

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Gujjar, Abhinandan S]

Hi Thomas,

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, November 3, 2020 9:34 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>
> Cc: Akhil Goyal <akhil.goyal@nxp.com>; dev@dpdk.org; Doherty, Declan
> <declan.doherty@intel.com>; Honnappa.Nagarahalli@arm.com; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Vangati, Narender
> <narender.vangati@intel.com>; jerinj@marvell.com; Mcnamara, John
> <john.mcnamara@intel.com>; david.marchand@redhat.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Subject: Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue
> callback functions
> 
> 03/11/2020 08:44, Gujjar, Abhinandan S:
> > From: Akhil Goyal <akhil.goyal@nxp.com>
> > > As I suggested 2 times that there are documentation issues. Haven't
> > > seen a version To fix that. Please check it at your end and try
> > > fixing the timing of your system so that CI Can pick it for compilation.
> >
> > As far as I remember, I have pulled in all the comments from you for the
> previous patch.
> > >
> > > > I understand that we work in same time zone, getting feedback from
> > > > you in the mid night will not help me/you to pull this patch in.
> > > > A quick response will enable me to prepare patch set quickly and
> > > > send it
> > > across.
> > >
> > > I am not dedicatedly working on your patchset. I will work as per my
> priorities.
> >
> > It is same for me. End of the day, we have mutually agreed to get this feature
> in.
> >
> > > Had it been a CI pass for compilation for both documentation and
> > > code, it would have been applied last night. I could remove those
> > > extra spaces, but there are other issues also as the newly added
> > > APIs are not visible in html files generated. Please ensure that
> > > there are no issues in doxygen build issues and should be able to see the
> newly added APIs in html guides.
> >
> > This is the kind of information I was looking for, which was not
> > available in your previous patch. If this info had been available quickly, I
> would have prepared next patchset.
> 
> It seems you didn't do all the checks you are required to do.
> Please be kind with Akhil who is working hard for the community.
> If you want to accelerate the process, help by reviewing other patches.
> 
I have done enough follow ups with Akhil and we both agreed to get this into RC2.
I did not realize that CI did not pick up the patches because of mismatch with my system time.
All I am saying is giving this information would have helped me.

> > Anyway, I will post the next patch set.
> 
> This is too late.
> We are not supposed to add new API in -rc2, and for sure not after -rc2
> deadline.
> 
> > >
> > > And please note, do not top post your comments. It becomes difficult
> > > to read it in Archives.
> >
> > Ok
> 
> Yes please do not top post, use --in-reply-to to gather all versions in the same
> thread, and fix the clock of your machine.
Ok
> 
> 

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Akhil Goyal]

Hi Abhinandan,
> 
> Hi Thomas,
> 
> >
> > 03/11/2020 08:44, Gujjar, Abhinandan S:
> > > From: Akhil Goyal <akhil.goyal@nxp.com>
> > > > As I suggested 2 times that there are documentation issues. Haven't
> > > > seen a version To fix that. Please check it at your end and try
> > > > fixing the timing of your system so that CI Can pick it for compilation.
> > >
> > > As far as I remember, I have pulled in all the comments from you for the
> > previous patch.
> > > >
> > > > > I understand that we work in same time zone, getting feedback from
> > > > > you in the mid night will not help me/you to pull this patch in.
> > > > > A quick response will enable me to prepare patch set quickly and
> > > > > send it
> > > > across.
> > > >
> > > > I am not dedicatedly working on your patchset. I will work as per my
> > priorities.
> > >
> > > It is same for me. End of the day, we have mutually agreed to get this
> feature
> > in.
> > >
> > > > Had it been a CI pass for compilation for both documentation and
> > > > code, it would have been applied last night. I could remove those
> > > > extra spaces, but there are other issues also as the newly added
> > > > APIs are not visible in html files generated. Please ensure that
> > > > there are no issues in doxygen build issues and should be able to see the
> > newly added APIs in html guides.
> > >
> > > This is the kind of information I was looking for, which was not
> > > available in your previous patch. If this info had been available quickly, I
> > would have prepared next patchset.
> >
> > It seems you didn't do all the checks you are required to do.
> > Please be kind with Akhil who is working hard for the community.
> > If you want to accelerate the process, help by reviewing other patches.
> >
> I have done enough follow ups with Akhil and we both agreed to get this into
> RC2.
> I did not realize that CI did not pick up the patches because of mismatch with my
> system time.
> All I am saying is giving this information would have helped me.

I highlighted the documentation issue and the system timing on Friday itself.
When the fix was not there on Monday, I tried to fix on my side which took me late
To comment back. Had it been done by CI, it would have been faster.

> 
> > > Anyway, I will post the next patch set.
> >
> > This is too late.
> > We are not supposed to add new API in -rc2, and for sure not after -rc2
> > deadline.
> >
> > > >
> > > > And please note, do not top post your comments. It becomes difficult
> > > > to read it in Archives.
> > >
> > > Ok
> >
> > Yes please do not top post, use --in-reply-to to gather all versions in the same
> > thread, and fix the clock of your machine.
> Ok
> >
> >

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Gujjar, Abhinandan S]

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Tuesday, November 3, 2020 10:23 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: dev@dpdk.org; Doherty, Declan <declan.doherty@intel.com>;
> Honnappa.Nagarahalli@arm.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Vangati, Narender
> <narender.vangati@intel.com>; jerinj@marvell.com; Mcnamara, John
> <john.mcnamara@intel.com>; david.marchand@redhat.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Subject: RE: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue
> callback functions
> 
> Hi Abhinandan,
> >
> > Hi Thomas,
> >
> > >
> > > 03/11/2020 08:44, Gujjar, Abhinandan S:
> > > > From: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > As I suggested 2 times that there are documentation issues.
> > > > > Haven't seen a version To fix that. Please check it at your end
> > > > > and try fixing the timing of your system so that CI Can pick it for
> compilation.
> > > >
> > > > As far as I remember, I have pulled in all the comments from you
> > > > for the
> > > previous patch.
> > > > >
> > > > > > I understand that we work in same time zone, getting feedback
> > > > > > from you in the mid night will not help me/you to pull this patch in.
> > > > > > A quick response will enable me to prepare patch set quickly
> > > > > > and send it
> > > > > across.
> > > > >
> > > > > I am not dedicatedly working on your patchset. I will work as
> > > > > per my
> > > priorities.
> > > >
> > > > It is same for me. End of the day, we have mutually agreed to get
> > > > this
> > feature
> > > in.
> > > >
> > > > > Had it been a CI pass for compilation for both documentation and
> > > > > code, it would have been applied last night. I could remove
> > > > > those extra spaces, but there are other issues also as the newly
> > > > > added APIs are not visible in html files generated. Please
> > > > > ensure that there are no issues in doxygen build issues and
> > > > > should be able to see the
> > > newly added APIs in html guides.
> > > >
> > > > This is the kind of information I was looking for, which was not
> > > > available in your previous patch. If this info had been available
> > > > quickly, I
> > > would have prepared next patchset.
> > >
> > > It seems you didn't do all the checks you are required to do.
> > > Please be kind with Akhil who is working hard for the community.
> > > If you want to accelerate the process, help by reviewing other patches.
> > >
> > I have done enough follow ups with Akhil and we both agreed to get
> > this into RC2.
> > I did not realize that CI did not pick up the patches because of
> > mismatch with my system time.
> > All I am saying is giving this information would have helped me.
> 
> I highlighted the documentation issue and the system timing on Friday itself.
> When the fix was not there on Monday, I tried to fix on my side which took me
> late To comment back. Had it been done by CI, it would have been faster.
What is the next step?

> 
> >
> > > > Anyway, I will post the next patch set.
> > >
> > > This is too late.
> > > We are not supposed to add new API in -rc2, and for sure not after
> > > -rc2 deadline.
> > >
> > > > >
> > > > > And please note, do not top post your comments. It becomes
> > > > > difficult to read it in Archives.
> > > >
> > > > Ok
> > >
> > > Yes please do not top post, use --in-reply-to to gather all versions
> > > in the same thread, and fix the clock of your machine.
> > Ok
> > >
> > >

Re: [dpdk-dev] [v6 1/2] cryptodev: support enqueue & dequeue callback functions

[Akhil Goyal]

> 
> Hi Akhil,
> 
> > Hi Abhinandan,
> > >
> > > Hi Thomas,
> > >
> > > >
> > > > 03/11/2020 08:44, Gujjar, Abhinandan S:
> > > > > From: Akhil Goyal <akhil.goyal@nxp.com>
> > > > > > As I suggested 2 times that there are documentation issues.
> > > > > > Haven't seen a version To fix that. Please check it at your end
> > > > > > and try fixing the timing of your system so that CI Can pick it for
> > compilation.
> > > > >
> > > > > As far as I remember, I have pulled in all the comments from you
> > > > > for the
> > > > previous patch.
> > > > > >
> > > > > > > I understand that we work in same time zone, getting feedback
> > > > > > > from you in the mid night will not help me/you to pull this patch in.
> > > > > > > A quick response will enable me to prepare patch set quickly
> > > > > > > and send it
> > > > > > across.
> > > > > >
> > > > > > I am not dedicatedly working on your patchset. I will work as
> > > > > > per my
> > > > priorities.
> > > > >
> > > > > It is same for me. End of the day, we have mutually agreed to get
> > > > > this
> > > feature
> > > > in.
> > > > >
> > > > > > Had it been a CI pass for compilation for both documentation and
> > > > > > code, it would have been applied last night. I could remove
> > > > > > those extra spaces, but there are other issues also as the newly
> > > > > > added APIs are not visible in html files generated. Please
> > > > > > ensure that there are no issues in doxygen build issues and
> > > > > > should be able to see the
> > > > newly added APIs in html guides.
> > > > >
> > > > > This is the kind of information I was looking for, which was not
> > > > > available in your previous patch. If this info had been available
> > > > > quickly, I
> > > > would have prepared next patchset.
> > > >
> > > > It seems you didn't do all the checks you are required to do.
> > > > Please be kind with Akhil who is working hard for the community.
> > > > If you want to accelerate the process, help by reviewing other patches.
> > > >
> > > I have done enough follow ups with Akhil and we both agreed to get
> > > this into RC2.
> > > I did not realize that CI did not pick up the patches because of
> > > mismatch with my system time.
> > > All I am saying is giving this information would have helped me.
> >
> > I highlighted the documentation issue and the system timing on Friday itself.
> > When the fix was not there on Monday, I tried to fix on my side which took me
> > late To comment back. Had it been done by CI, it would have been faster.
> What is the next step?
> 
I have closed the crypto tree for RC2, and it is upto Thomas to take it directly on main branch.