From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2018 04:18:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,346,1520924400"; d="scan'208";a="51112552" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by fmsmga001.fm.intel.com with ESMTP; 30 Apr 2018 04:18:08 -0700 Received: from pgsmsx102.gar.corp.intel.com ([169.254.6.245]) by KMSMSX152.gar.corp.intel.com ([169.254.11.169]) with mapi id 14.03.0319.002; Mon, 30 Apr 2018 19:18:07 +0800 From: "Gujjar, Abhinandan S" To: Jerin Jacob CC: "hemant.agrawal@nxp.com" , "akhil.goyal@nxp.com" , "dev@dpdk.org" , "Vangati, Narender" , "Rao, Nikhil" , "Eads, Gage" Thread-Topic: [v2,3/6] eventdev: add crypto adapter implementation Thread-Index: AQHT28nkP/Ti+L5nqUKVBBotSI+yAKQXbvWAgAHCfnA= 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> In-Reply-To: <20180429162251.GC11546@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDYxYmFkZDQtMDZmOC00YTE2LTgyMjUtOGNlZDkwYmI0ZThiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImlXaHlYRWdJZVdZMmdncjhsenkwY1wvWDVCZW51enlEZ3dFOVNTNlFDT1dvPSJ9 dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [v2, 3/6] eventdev: add crypto adapter implementation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 11:18:12 -0000 > -----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