> > > @@ -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.

Reply via email to