From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gujjar, Abhinandan S" Subject: Re: [v2, 3/6] eventdev: add crypto adapter implementation Date: Mon, 30 Apr 2018 11:18:08 +0000 Message-ID: <5612CB344B05EE4F95FC5B729939F78070700DFB@PGSMSX102.gar.corp.intel.com> References: <1524573807-168522-1-git-send-email-abhinandan.gujjar@intel.com> <1524573807-168522-4-git-send-email-abhinandan.gujjar@intel.com> <20180429162251.GC11546@jerin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "hemant.agrawal@nxp.com" , "akhil.goyal@nxp.com" , "dev@dpdk.org" , "Vangati, Narender" , "Rao, Nikhil" , "Eads, Gage" To: Jerin Jacob Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 9F9A5DD2 for ; Mon, 30 Apr 2018 13:18:11 +0200 (CEST) In-Reply-To: <20180429162251.GC11546@jerin> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Sunday, April 29, 2018 9:53 PM > To: Gujjar, Abhinandan S > Cc: hemant.agrawal@nxp.com; akhil.goyal@nxp.com; dev@dpdk.org; Vangati, > Narender ; Rao, Nikhil = ; > Eads, Gage > Subject: Re: [v2,3/6] eventdev: add crypto adapter implementation >=20 > -----Original Message----- > > Date: Tue, 24 Apr 2018 18:13:24 +0530 > > From: Abhinandan Gujjar > > To: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, > > akhil.goyal@nxp.com, dev@dpdk.org > > CC: narender.vangati@intel.com, abhinandan.gujjar@intel.com, > > nikhil.rao@intel.com, gage.eads@intel.com > > Subject: [v2,3/6] eventdev: add crypto adapter implementation > > X-Mailer: git-send-email 1.9.1 > > > > Signed-off-by: Abhinandan Gujjar > > Signed-off-by: Nikhil Rao > > Signed-off-by: Gage Eads > > --- > > + > > +/* 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; > > +}; >=20 > Looks like it is used in fastpath, if so add the cache alignment. Sure. >=20 > > + > > +/* 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 =3D &adapter->crypto_sta= ts; > > + union rte_event_crypto_metadata *m_data =3D NULL; > > + struct crypto_queue_pair_info *qp_info =3D NULL; > > + struct rte_crypto_op *crypto_op; > > + unsigned int i, n =3D 0; > > + uint16_t qp_id =3D 0, len =3D 0, ret =3D 0; >=20 > 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? >=20 > > + uint8_t cdev_id =3D 0; > > + > > + stats->event_dequeue_count +=3D cnt; > > + > > + for (i =3D 0; i < cnt; i++) { > > + crypto_op =3D ev[i].event_ptr; > > + if (crypto_op =3D=3D NULL) > > + continue; > > + if (crypto_op->sess_type =3D=3D RTE_CRYPTO_OP_WITH_SESSION) { > > + m_data =3D > rte_cryptodev_sym_session_get_private_data( > > + crypto_op->sym->session); > > + if (m_data =3D=3D NULL) { > > + rte_pktmbuf_free(crypto_op->sym->m_src); > > + rte_crypto_op_free(crypto_op); > > + continue; > > + } > > + > > + cdev_id =3D m_data->request_info.cdev_id; > > + qp_id =3D m_data->request_info.queue_pair_id; > > + qp_info =3D &adapter->cdevs[cdev_id].qpairs[qp_id]; > > + if (qp_info =3D=3D NULL) { > > + rte_pktmbuf_free(crypto_op->sym->m_src); > > + rte_crypto_op_free(crypto_op); > > + continue; > > + } > > + len =3D qp_info->len; > > + qp_info->op_buffer[len] =3D 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=3D%" PRIu8, cdev_id); > > + return -EINVAL; > > + } > > + > > + adapter =3D eca_id_to_adapter(id); > > + if (adapter =3D=3D NULL) > > + return -EINVAL; > > + > > + dev =3D &rte_eventdevs[adapter->eventdev_id]; > > + ret =3D 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 =3D=3D RTE_EVENT_CRYPTO_ADAPTER_ENQ_DEQ) || > cap) { > > + rte_spinlock_lock(&adapter->lock); > > + ret =3D eca_init_service(adapter, id); > > + if (ret =3D=3D 0) > > + ret =3D 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); >=20 > I guess, it will be called in HW case, if so, please move to appropriate = place. Ok >=20 > > + > > + 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 =3D 0; >=20 > No need for explicit '0' assignment >=20