Hi Abhinandan,
> > > +static int
> > > +cryptodev_cb_init(struct rte_cryptodev *dev) {
> > > + struct rte_cryptodev_enq_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_enq_cb_rcu) *
> > > + dev->data->nb_queue_pairs, 0);
> > > + if (dev->enq_cbs == NULL) {
> > > + CDEV_LOG_ERR("Failed to allocate memory for callbacks");
> > > + rte_errno = ENOMEM;
> > > + return -1;
> > > + }
> >
> > Why not return ENOMEM here? You are not using rte_errno while returning
> > from this function, so setting it does not have any meaning.
> This is a internal function. The caller is returning ENOMEM.
The caller can return the returned value from cryptodev_cb_init, instead of
explicitly
Returning ENOMEM.
There is no point of setting rte_errno here.
> > > /** The data structure associated with each crypto device. */ struct
> > > rte_cryptodev {
> > > dequeue_pkt_burst_t dequeue_burst;
> > > @@ -867,6 +922,10 @@ struct rte_cryptodev {
> > > __extension__
> > > uint8_t attached : 1;
> > > /**< Flag indicating the device is attached */
> > > +
> > > + struct rte_cryptodev_enq_cb_rcu *enq_cbs;
> > > + /**< User application callback for pre enqueue processing */
> > > +
> > Extra line
> ok
> >
> > We should add support for post dequeue callbacks also. Since this is an LTS
> > release And we wont be very flexible in future quarterly release, we should
> > do
> > all the changes In one go.
> This patch set is driven by requirement. Recently, we have a requirement to
> have
> callback for dequeue as well. Looking at code freeze date, I am not sure we
> can
> target that as well. Let this patch go in and I will send a separate patch for
> dequeue callback.
>
We may not be able to change the rte_cryptodev structure so frequently.
It may be allowed to change it 21.11 release. Which is too far.
I think atleast the cryptodev changes can go in RC2 and test app for deq cbs
Can go in RC3 if not RC2.
> > I believe we should also double check with techboard if this is an ABI
> > breakage.
> > IMO, it is ABI breakage, rte_cryprodevs is part of stable APIs, but not
> > sure.
> >
> > > } __rte_cache_aligned;
> > >
> > >
> > > +#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.
> >
> > Is there a limit for the number of cbs that can be added? Better to add a
> > Comment here.
I think you missed this comment.
