> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Sunday, April 29, 2018 9:53 PM
> To: Gujjar, Abhinandan S <abhinandan.guj...@intel.com>
> Cc: hemant.agra...@nxp.com; akhil.go...@nxp.com; dev@dpdk.org; Vangati,
> Narender <narender.vang...@intel.com>; Rao, Nikhil <nikhil....@intel.com>;
> Eads, Gage <gage.e...@intel.com>
> Subject: Re: [v2,3/6] eventdev: add crypto adapter implementation
>
> -----Original Message-----
> > Date: Tue, 24 Apr 2018 18:13:24 +0530
> > From: Abhinandan Gujjar <abhinandan.guj...@intel.com>
> > To: jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
> > akhil.go...@nxp.com, dev@dpdk.org
> > CC: narender.vang...@intel.com, abhinandan.guj...@intel.com,
> > nikhil....@intel.com, gage.e...@intel.com
> > Subject: [v2,3/6] eventdev: add crypto adapter implementation
> > X-Mailer: git-send-email 1.9.1
> >
> > Signed-off-by: Abhinandan Gujjar <abhinandan.guj...@intel.com>
> > Signed-off-by: Nikhil Rao <nikhil....@intel.com>
> > Signed-off-by: Gage Eads <gage.e...@intel.com>
> > ---
> > +
> > +/* Per crypto device information */
> > +struct crypto_device_info {
> > + /* Pointer to cryptodev */
> > + struct rte_cryptodev *dev;
> > + /* Pointer to queue pair info */
> > + struct crypto_queue_pair_info *qpairs;
> > + /* Next queue pair to be processed */
> > + uint16_t next_queue_pair_id;
> > + /* Set to indicate cryptodev->eventdev packet
> > + * transfer uses a hardware mechanism
> > + */
> > + uint8_t internal_event_port;
> > + /* Set to indicate processing has been started */
> > + uint8_t dev_started;
> > + /* If num_qpairs > 0, the start callback will
> > + * be invoked if not already invoked
> > + */
> > + uint16_t num_qpairs;
> > +};
>
> Looks like it is used in fastpath, if so add the cache alignment.
Sure.
>
> > +
> > +/* Per queue pair information */
> > +struct crypto_queue_pair_info {
> > + /* Set to indicate queue pair is enabled */
> > + bool qp_enabled;
> > + /* Pointer to hold rte_crypto_ops for batching */
> > + struct rte_crypto_op **op_buffer;
> > + /* No of crypto ops accumulated */
> > + uint8_t len;
> > +};
> > +
> > +static struct rte_event_crypto_adapter **event_crypto_adapter;
> > +
> > +eca_enq_to_cryptodev(struct rte_event_crypto_adapter *adapter,
> > + struct rte_event *ev, unsigned int cnt) {
> > + struct rte_event_crypto_adapter_stats *stats = &adapter->crypto_stats;
> > + union rte_event_crypto_metadata *m_data = NULL;
> > + struct crypto_queue_pair_info *qp_info = NULL;
> > + struct rte_crypto_op *crypto_op;
> > + unsigned int i, n = 0;
> > + uint16_t qp_id = 0, len = 0, ret = 0;
>
> Please review the explicit '0' assignment.
I have initialized only those, which are complained by gcc.
I will look at it again. If required, I will initialize them separately. Is
that ok?
>
> > + uint8_t cdev_id = 0;
> > +
> > + stats->event_dequeue_count += cnt;
> > +
> > + for (i = 0; i < cnt; i++) {
> > + crypto_op = ev[i].event_ptr;
> > + if (crypto_op == NULL)
> > + continue;
> > + if (crypto_op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
> > + m_data =
> rte_cryptodev_sym_session_get_private_data(
> > + crypto_op->sym->session);
> > + if (m_data == NULL) {
> > + rte_pktmbuf_free(crypto_op->sym->m_src);
> > + rte_crypto_op_free(crypto_op);
> > + continue;
> > + }
> > +
> > + cdev_id = m_data->request_info.cdev_id;
> > + qp_id = m_data->request_info.queue_pair_id;
> > + qp_info = &adapter->cdevs[cdev_id].qpairs[qp_id];
> > + if (qp_info == NULL) {
> > + rte_pktmbuf_free(crypto_op->sym->m_src);
> > + rte_crypto_op_free(crypto_op);
> > + continue;
> > + }
> > + len = qp_info->len;
> > + qp_info->op_buffer[len] = crypto_op;
> > + len++;
> > +
> > +int __rte_experimental
> > +rte_event_crypto_adapter_queue_pair_add(uint8_t id,
> > + uint8_t cdev_id,
> > + int32_t queue_pair_id,
> > + const struct rte_event_crypto_queue_pair_conf *conf)
> {
> > + struct rte_event_crypto_adapter *adapter;
> > + struct rte_eventdev *dev;
> > + struct crypto_device_info *dev_info;
> > + uint32_t cap;
> > + int ret;
> > +
> > + RTE_EVENT_CRYPTO_ADAPTER_ID_VALID_OR_ERR_RET(id, -EINVAL);
> > +
> > + if (!rte_cryptodev_pmd_is_valid_dev(cdev_id)) {
> > + RTE_EDEV_LOG_ERR("Invalid dev_id=%" PRIu8, cdev_id);
> > + return -EINVAL;
> > + }
> > +
> > + adapter = eca_id_to_adapter(id);
> > + if (adapter == NULL)
> > + return -EINVAL;
> > +
> > + dev = &rte_eventdevs[adapter->eventdev_id];
> > + ret = rte_event_crypto_adapter_caps_get(adapter->eventdev_id,
> > + cdev_id,
> > + &cap);
> > + if (ret) {
> > + if ((cap &
> RTE_EVENT_CRYPTO_ADAPTER_CAP_INTERNAL_PORT_OP_NEW &&
> > + adapter->mode == RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ) ||
> cap) {
> > + rte_spinlock_lock(&adapter->lock);
> > + ret = eca_init_service(adapter, id);
> > + if (ret == 0)
> > + ret = eca_add_queue_pair(adapter, cdev_id,
> > + queue_pair_id);
> > + rte_spinlock_unlock(&adapter->lock);
> > + }
> > +
> > + if (ret)
> > + return ret;
> > +
> > + rte_service_component_runstate_set(adapter->service_id, 1);
>
> I guess, it will be called in HW case, if so, please move to appropriate
> place.
Ok
>
> > +
> > + return 0;
> > +}
> > +
> > +int __rte_experimental
> > +rte_event_crypto_adapter_queue_pair_del(uint8_t id, uint8_t cdev_id,
> > + int32_t queue_pair_id)
> > +{
> > + struct rte_event_crypto_adapter *adapter;
> > + struct crypto_device_info *dev_info;
> > + struct rte_eventdev *dev;
> > + int ret = 0;
>
> No need for explicit '0' assignment
>
