Hi Fiona >-----Original Message----- >From: Trahe, Fiona [mailto:fiona.tr...@intel.com] >Sent: 06 July 2018 19:11 >To: Verma, Shally <shally.ve...@cavium.com>; De Lara Guarch, Pablo ><pablo.de.lara.gua...@intel.com> >Cc: dev@dpdk.org; Athreya, Narayana Prasad ><narayanaprasad.athr...@cavium.com>; Murthy, Nidadavolu ><nidadavolu.mur...@cavium.com>; Kartha, Umesh <umesh.kar...@cavium.com>; Sahu, >Sunila <sunila.s...@cavium.com>; Gupta, >Ashish <ashish.gu...@cavium.com>; Trahe, Fiona <fiona.tr...@intel.com> >Subject: RE: [dpdk-dev] [PATCH v4 2/4] cryptodev: support asymmetric operations > >External Email > >Hi Shally, Umesh, > >> -----Original Message----- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shally Verma >> Sent: Tuesday, July 3, 2018 4:24 PM >> To: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com> >> Cc: dev@dpdk.org; pathr...@caviumnetworks.com; nmur...@caviumnetworks.com; >> Umesh Kartha >> <umesh.kar...@caviumnetworks.com>; Sunila Sahu >> <sunila.s...@caviumnetworks.com>; Ashish >> Gupta <ashish.gu...@caviumnetworks.com> >> Subject: [dpdk-dev] [PATCH v4 2/4] cryptodev: support asymmetric operations > > >//snip// >> + >> +int __rte_experimental >> +rte_cryptodev_asym_session_set_private_data( >> + struct rte_cryptodev_asym_session >> *sess, >> + void *data, >> + uint16_t size) >> +{ >> + uint16_t off_set = sizeof(void *) * nb_drivers; >> + uint8_t *private_data_present = (uint8_t *)sess + off_set; >> + >> + if (sess == NULL) >> + return -EINVAL; >> + >> + *private_data_present = 1; >> + off_set += sizeof(uint8_t); >> + rte_memcpy((uint8_t *)sess + off_set, data, size); >> + return 0; >> +} >> + >> +void * __rte_experimental >> +rte_cryptodev_asym_session_get_app_private_data( >> + struct rte_cryptodev_asym_session *sess) >[Fiona] The set api should be renamed if the get function is renamed. >However, I'd suggest leaving out these functions unless they're really needed >for asymm. >Are they just here for consistency with the sym functions? >The sym functions are still experimental and I think the names should be >changed to >use user_data instead of private_data. >I've just sent a patch to the mailing list about this - it would be better to >resolve that naming >issue first and add corresponding fns later to this api if needed.
Ya . right now they were there for consistency. You prefer to remove them? Thanks Shally
