[dpdk-dev] [PATCH 3/8] cryptodev: add helper functions for new datapath interface
Akhil Goyal
gakhil at marvell.com
Tue Aug 31 08:14:29 CEST 2021
Hi Fan,
> Hi Akhil,
>
> > +__rte_internal
> > +static inline void *
> > +_rte_cryptodev_dequeue_prolog(uint8_t dev_id, uint8_t qp_id)
> > +{
> > + struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> > +
> > + return dev->data->queue_pairs[qp_id];
> > +}
>
> [Fan: the function name looks unclear to me - maybe
> rte_cryptodev_dequeue_prepare?
The naming convention is same as Konstantin did for ethdev and
Subsequently by Pavan in eventdev. I think it is better to align all
With similar naming.
> Also the function didn't do any check as the description suggested - the
> qp is later checked in _RTE_CRYPTO_DEQ_DEF, maybe remove the
> description?]
>
Ok will update the description in next version
> > +_rte_cryptodev_dequeue_epilog(uint16_t dev_id, uint16_t qp_id,
> > + struct rte_crypto_op **ops, uint16_t nb_ops)
> > +{
> > +#ifdef RTE_CRYPTO_CALLBACKS
> > + struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> > +
> > + if (unlikely(dev->deq_cbs != NULL)) {
> > + struct rte_cryptodev_cb_rcu *list;
> > + struct rte_cryptodev_cb *cb;
> > +
> > + /* __ATOMIC_RELEASE memory order was used when the
> > + * call back was inserted into the list.
> > + * Since there is a clear dependency between loading
> > + * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory
> > order is
> > + * not required.
> > + */
> > + list = &dev->deq_cbs[qp_id];
> > + rte_rcu_qsbr_thread_online(list->qsbr, 0);
> > + cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
> > +
> > + while (cb != NULL) {
> > + nb_ops = cb->fn(dev_id, qp_id, ops, nb_ops,
> > + cb->arg);
> > + cb = cb->next;
> > + };
> > +
> > + rte_rcu_qsbr_thread_offline(list->qsbr, 0);
> > + }
> > +#endif
> > +
> > + return nb_ops;
> > +}
>
> [Fan: same naming issue - maybe rte_cryptodev_dequeue_post, so
> as the enqueue part]
Same comment as above. Aligned with ethdev and eventdev changes.
>
> > +#define _RTE_CRYPTO_DEQ_FUNC(fn) _rte_crypto_deq_##fn
> > +
> > +/**
> > + * @internal
> > + * Helper macro to create new API wrappers for existing PMD dequeue
> > functions.
> > + */
> > +#define _RTE_CRYPTO_DEQ_PROTO(fn) \
> > + uint16_t _RTE_CRYPTO_DEQ_FUNC(fn)(uint8_t dev_id, uint8_t
> > qp_id, \
> > + struct rte_crypto_op **ops, uint16_t nb_ops)
> > +
> > +/**
> > + * @internal
> > + * Helper macro to create new API wrappers for existing PMD dequeue
> > functions.
> > + */
> > +#define _RTE_CRYPTO_DEQ_DEF(fn) \
> > +_RTE_CRYPTO_DEQ_PROTO(fn) \
> > +{ \
> > + void *qp = _rte_cryptodev_dequeue_prolog(dev_id, qp_id); \
> > + if (qp == NULL) \
> [Fan: suggest to add "unlikely" above]
Ok
More information about the dev
mailing list