[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