[dpdk-dev] [PATCH v3 6/7] cryptodev: update fast path APIs to use new flat array

Ananyev, Konstantin konstantin.ananyev at intel.com
Tue Oct 19 16:25:01 CEST 2021



 
> > > @@ -1832,13 +1832,18 @@ static inline uint16_t
> > >  rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> > >  		struct rte_crypto_op **ops, uint16_t nb_ops)
> > >  {
> > > -	struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> > > +	const struct rte_crypto_fp_ops *fp_ops;
> > > +	void *qp;
> > >
> > >  	rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops,
> > nb_ops);
> > > -	nb_ops = (*dev->dequeue_burst)
> > > -			(dev->data->queue_pairs[qp_id], ops, nb_ops);
> > > +
> > > +	fp_ops = &rte_crypto_fp_ops[dev_id];
> > > +	qp = fp_ops->qp.data[qp_id];
> > > +
> > > +	nb_ops = fp_ops->dequeue_burst(qp, ops, nb_ops);
> > > +
> > >  #ifdef RTE_CRYPTO_CALLBACKS
> > > -	if (unlikely(dev->deq_cbs != NULL)) {
> > > +	if (unlikely(fp_ops->qp.deq_cb != NULL)) {
> > >  		struct rte_cryptodev_cb_rcu *list;
> > >  		struct rte_cryptodev_cb *cb;
> >
> > As I ca see you decided to keep call-back related data-structs as public API.
> > I wonder that's to avoid extra changes with CB related code?
> > Or performance reasons?
> > Or probably something else?
> I just wanted to avoid extra changes and it did not look that important at this point
> Compared to other patches.
> I would have done the changes if I had some more time.

Understood, thanks for explanation.



More information about the dev mailing list