DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gujjar, Abhinandan S" <abhinandan.gujjar@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	"akhil.goyal@nxp.com" <akhil.goyal@nxp.com>,
	"Honnappa.Nagarahalli@arm.com" <Honnappa.Nagarahalli@arm.com>
Cc: "Vangati, Narender" <narender.vangati@intel.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [v3 1/2] cryptodev: support enqueue callback functions
Date: Fri, 23 Oct 2020 12:36:23 +0000	[thread overview]
Message-ID: <MWHPR11MB1838A96EAC9BB5943BEC3747E81A0@MWHPR11MB1838.namprd11.prod.outlook.com> (raw)
In-Reply-To: <BYAPR11MB3301B1ADC5FB84915F4494189A1C0@BYAPR11MB3301.namprd11.prod.outlook.com>

Hi Konstantin,

Thanks. I will generate a new patch with suggested changes.

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Thursday, October 22, 2020 1:04 AM
> To: Gujjar, Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Doherty, Declan <declan.doherty@intel.com>; akhil.goyal@nxp.com;
> Honnappa.Nagarahalli@arm.com
> Cc: Vangati, Narender <narender.vangati@intel.com>; jerinj@marvell.com
> Subject: RE: [v3 1/2] cryptodev: support enqueue callback functions
> 
> 
> Hi Abhinandan,
> 
> Thanks for the effort, good progress.
> Though few more comments, see below.
> 
> > This patch adds APIs to add/remove callback functions. The callback
> > function will be called for each burst of crypto ops received on a
> > given crypto device queue pair.
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.gujjar@intel.com>
> > ---
> >  config/rte_config.h                            |   1 +
> >  lib/librte_cryptodev/meson.build               |   2 +-
> >  lib/librte_cryptodev/rte_cryptodev.c           | 201
> +++++++++++++++++++++++++
> >  lib/librte_cryptodev/rte_cryptodev.h           | 153 ++++++++++++++++++-
> >  lib/librte_cryptodev/rte_cryptodev_version.map |   2 +
> >  5 files changed, 357 insertions(+), 2 deletions(-)
> 
> Don't forget to update Release Notes and probably Prog Guide too.
> 
> >
> > diff --git a/config/rte_config.h b/config/rte_config.h index
> > 03d90d7..e999d93 100644
> > --- a/config/rte_config.h
> > +++ b/config/rte_config.h
> > @@ -61,6 +61,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/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..5ba774a 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.c
> > +++ b/lib/librte_cryptodev/rte_cryptodev.c
> > @@ -448,6 +448,10 @@ 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_enq_cb_lock = RTE_SPINLOCK_INITIALIZER; #endif
> >
> >  const char *
> >  rte_cryptodev_get_feature_name(uint64_t flag) @@ -1136,6 +1140,203 @@
> > 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 *cb, *tail;
> > +	struct rte_cryptodev_enq_cb_rcu *list;
> > +	struct rte_rcu_qsbr *qsbr;
> > +	size_t size;
> > +
> > +	/* Max thread set to 1, as one DP thread accessing a queue-pair */
> > +	const uint32_t max_threads = 1;
> > +
> > +	if (!cb_fn)
> > +		return NULL;
> > +
> > +	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > +		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> > +		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);
> > +		return NULL;
> > +	}
> > +
> > +	rte_spinlock_lock(&rte_cryptodev_enq_cb_lock);
> > +	if (dev->enq_cbs == NULL) {
> > +		dev->enq_cbs = rte_zmalloc(NULL, sizeof(cb) *
> > +					   dev->data->nb_queue_pairs, 0);
> > +		if (dev->enq_cbs == NULL) {
> > +			CDEV_LOG_ERR("Failed to allocate memory for
> callbacks");
> > +			rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> 
> It is a bit clumsy to do unlock() for every return with error.
> Probably an  easier way - create an internal function that would do the actual
> job, and then lock(); ret=actual_job_internal_functio(...); unlock();...
> 
> > +			rte_errno = ENOMEM;
> > +			return NULL;
> > +		}
> > +
> > +		list = rte_zmalloc(NULL, sizeof(*list), 0);
> 
> As I understand, list is per queue, while enq_cbs[] is per port.
> So if enq_cbs is not null, it doesn't mean that list for that particular queue is
> already properly initialized.
> 
> Another thing - is there any point for dev->enq_cbs[] to be a an array of
> pointers to rte_cryptodev_enq_cb_rcu? Considering that
> rte_cryptodev_enq_cb_rcu itself contains just two pointers inside, I think it
> enq_cbs can point just to an array of rte_cryptodev_enq_cb_rcu:
> 
> struct rte_cryptodev {
> 	...
> 	struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> 
> And you can remove one level of indirection here and in other places.
> 
> > +		if (list == NULL) {
> > +			CDEV_LOG_ERR("Failed to allocate memory for list on
> "
> > +				"dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > +			rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +			rte_errno = ENOMEM;
> > +			rte_free(dev->enq_cbs);
> 
> Here and in other places: you free dev->enq_cbs, but not set it to NULL.
> In fact - probably a good idea to have one cleanup() function that would free all
> necessary stuff and set it to null, and then use it in all such places.
> 
> > +			return NULL;
> > +		}
> > +
> > +		/* Create RCU QSBR variable */
> > +		size = rte_rcu_qsbr_get_memsize(max_threads);
> > +		qsbr = rte_zmalloc(NULL, size, RTE_CACHE_LINE_SIZE);
> > +		if (qsbr == NULL) {
> > +			CDEV_LOG_ERR("Failed to allocate memory for RCU
> on "
> > +				"dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > +			rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +			rte_errno = ENOMEM;
> > +			rte_free(list);
> > +			rte_free(dev->enq_cbs);
> > +			dev->enq_cbs[qp_id] = NULL;
> > +			return NULL;
> > +		}
> > +
> > +		if (rte_rcu_qsbr_init(qsbr, max_threads)) {
> > +			CDEV_LOG_ERR("Failed to initialize for RCU on "
> > +				"dev=%d, queue_pair_id=%d", dev_id, qp_id);
> > +			rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +			rte_free(qsbr);
> > +			rte_free(list);
> > +			rte_free(dev->enq_cbs);
> > +			dev->enq_cbs[qp_id] = NULL;
> > +			return NULL;
> > +		}
> > +
> > +		dev->enq_cbs[qp_id] = list;
> > +		list->qsbr = qsbr;
> > +	}
> > +
> > +	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_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +		rte_errno = ENOMEM;
> > +		return NULL;
> > +	}
> > +
> > +	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;
> > +		tail->next = cb;
> > +	} else
> > +		list->next = cb;
> > +
> > +	rte_spinlock_unlock(&rte_cryptodev_enq_cb_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_enq_cb_rcu *list;
> > +	uint16_t qp;
> > +	int free_mem;
> > +	int ret;
> > +
> > +	free_mem = 1;
> > +	ret = -EINVAL;
> > +
> > +	if (!cb) {
> > +		CDEV_LOG_ERR("cb is NULL");
> > +		return ret;
> > +	}
> > +
> > +	if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
> > +		CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
> > +		return ret;
> > +	}
> > +
> > +	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 ret;
> > +	}
> > +
> > +	list = dev->enq_cbs[qp_id];
> > +	if (list == NULL) {
> > +		CDEV_LOG_ERR("Callback list is NULL");
> > +		return ret;
> > +	}
> > +
> > +	if (list->qsbr == NULL) {
> > +		CDEV_LOG_ERR("Rcu qsbr is NULL");
> > +		return ret;
> > +	}
> > +
> > +	rte_spinlock_lock(&rte_cryptodev_enq_cb_lock);
> > +	if (dev->enq_cbs == NULL) {
> > +		rte_spinlock_unlock(&rte_cryptodev_enq_cb_lock);
> > +		return ret;
> > +	}
> > +
> > +	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. */
> > +			*prev_cb = curr_cb->next;
> > +			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);
> > +	}
> > +
> > +	if (list->next == NULL) {
> > +		rte_free(list->qsbr);
> 
> We can't destroy our sync variable while device is not stopped or destroyed.
> It can be still used by DP.
> Probably the easiest way to deal with it - allocate and initialize enq_cbs[] and
> all related qsbrs at first add_callback and free all that memory only on
> dev_destroy().
> 
> > +		rte_free(list);
> > +		dev->enq_cbs[qp_id] = NULL;
> > +	}
> > +
> > +	for (qp = 0; qp < dev->data->nb_queue_pairs; qp++)
> > +		if (dev->enq_cbs[qp] != NULL) {
> > +			free_mem = 0;
> > +			break;
> > +		}
> > +
> > +	if (free_mem) {
> > +		rte_free(dev->enq_cbs);
> 
> Again, not safe to do here, see above.
> 
> > +		dev->enq_cbs = NULL;
> > +	}
> > +
> > +	rte_spinlock_unlock(&rte_cryptodev_enq_cb_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..669746d 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,34 @@ struct rte_cryptodev_qp_conf {
> >  	/**< The mempool for creating sess private data in sessionless mode
> > */  };
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +/**
> > + * Function type used for pre processing crypto ops when enqueue
> > +burst is
> > + * called.
> > + *
> > + * The callback function is called on enqueue burst immediately
> > + * before the crypto ops are put onto the hardware queue for processing.
> > + *
> > + * @param	dev_id		The identifier of the device.
> > + * @param	qp_id		The index of the queue pair in 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	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 +851,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 +867,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.
> > + */
> > +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_enq_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 +922,11 @@ struct rte_cryptodev {
> >  	__extension__
> >  	uint8_t attached : 1;
> >  	/**< Flag indicating the device is attached */
> > +
> > +#ifdef RTE_CRYPTO_CALLBACKS
> 
> I'd *always* reserve space for it.
> No matter is RTE_CRYPTO_CALLBACKS defined or not.
> To avoid difference in public structure layout.
> 
> > +	struct rte_cryptodev_enq_cb_rcu **enq_cbs;
> 
> As I said above, no need for extra level of indirection.
> 
> > +	/**< User application callback for pre enqueue processing */ #endif
> 
> As I understand, it is not an ABI breakage - as there are some free space right
> now at the end of struct rte_cryptodev (due to it alignment), but definitely need
> to update RN.
> 
> 
> >  } __rte_cache_aligned;
> >
> >  void *
> > @@ -989,6 +1049,25 @@ struct rte_cryptodev_data {  {
> >  	struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> >
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > +	if (unlikely(dev->enq_cbs != NULL && dev->enq_cbs[qp_id] != NULL)) {
> 
> Agree with Honnappa's comment for that piece of code.
> Probably need to be something like:
> 
> if (unlikely(dev->enq_cbs != NULL && dev->enq_cbs[qp_id].next != NULL) {
> 	list = &dev->enq_cbs[qp_id];
> 	rte_rcu_qsbr_thread_online(list->qsbr, 0);
> 	for (cb = list->next; cb != NULL; cb = cb->next)
> 		....
> 	rte_rcu_qsbr_thread_offline(list->qsbr, 0); }
> 
> 
> > +		struct rte_cryptodev_enq_cb_rcu *list;
> > +		struct rte_cryptodev_cb *cb;
> > +
> > +		list = dev->enq_cbs[qp_id];
> > +		cb = list->next;
> > +		rte_rcu_qsbr_thread_online(list->qsbr, 0);
> > +
> > +		do {
> > +			nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> > +					cb->arg);
> > +			cb = cb->next;
> > +		} while (cb != NULL);
> > +
> > +		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 +1809,78
> > @@ 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().
> > + *
> > + * Multiple functions are called in the order that they are added.
> > + *
> > + * @param	dev_id		The identifier of the device.
> > + * @param	qp_id		The index of the queue pair in 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.
> > + *   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 removed 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 in 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		Pointer to user supplied callback created via
> > + *				rte_cryptodev_add_enq_callback().
> > + *
> > + * @return
> > + *   - 0: Success. Callback was removed.
> > + *   - -EINVAL:  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);
> > +
> > +#endif
> > +
> >  #ifdef __cplusplus
> >  }
> >  #endif
> > diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map
> > b/lib/librte_cryptodev/rte_cryptodev_version.map
> > index 7e4360f..5d8d6b0 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev_version.map
> > +++ b/lib/librte_cryptodev/rte_cryptodev_version.map
> > @@ -101,6 +101,7 @@ EXPERIMENTAL {
> >  	rte_cryptodev_get_qp_status;
> >
> >  	# added in 20.11
> > +	rte_cryptodev_add_enq_callback;
> >  	rte_cryptodev_configure_raw_dp_ctx;
> >  	rte_cryptodev_get_raw_dp_ctx_size;
> >  	rte_cryptodev_raw_dequeue;
> > @@ -109,4 +110,5 @@ EXPERIMENTAL {
> >  	rte_cryptodev_raw_enqueue;
> >  	rte_cryptodev_raw_enqueue_burst;
> >  	rte_cryptodev_raw_enqueue_done;
> > +	rte_cryptodev_remove_enq_callback;
> >  };
> > --
> > 1.9.1


  reply	other threads:[~2020-10-23 12:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19  2:57 [dpdk-dev] [v3 0/2] support enqueue callbacks on cryptodev Abhinandan Gujjar
2020-10-19  2:57 ` [dpdk-dev] [v3 1/2] cryptodev: support enqueue callback functions Abhinandan Gujjar
2020-10-21  7:28   ` Honnappa Nagarahalli
2020-10-23 12:34     ` Gujjar, Abhinandan S
2020-10-21 19:33   ` Ananyev, Konstantin
2020-10-23 12:36     ` Gujjar, Abhinandan S [this message]
2020-10-19  2:57 ` [dpdk-dev] [v3 2/2] test: add testcase for crypto enqueue callback Abhinandan Gujjar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MWHPR11MB1838A96EAC9BB5943BEC3747E81A0@MWHPR11MB1838.namprd11.prod.outlook.com \
    --to=abhinandan.gujjar@intel.com \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=akhil.goyal@nxp.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=narender.vangati@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).