Hi Fiona >-----Original Message----- >From: Trahe, Fiona [mailto:[email protected]] >Sent: 06 July 2018 19:11 >To: Verma, Shally <[email protected]>; De Lara Guarch, Pablo ><[email protected]> >Cc: [email protected]; Athreya, Narayana Prasad ><[email protected]>; Murthy, Nidadavolu ><[email protected]>; Kartha, Umesh <[email protected]>; Sahu, >Sunila <[email protected]>; Gupta, >Ashish <[email protected]>; Trahe, Fiona <[email protected]> >Subject: RE: [dpdk-dev] [PATCH v4 2/4] cryptodev: support asymmetric operations > >External Email > >Hi Shally, Umesh, > >> -----Original Message----- >> From: dev [mailto:[email protected]] On Behalf Of Shally Verma >> Sent: Tuesday, July 3, 2018 4:24 PM >> To: De Lara Guarch, Pablo <[email protected]> >> Cc: [email protected]; [email protected]; [email protected]; >> Umesh Kartha >> <[email protected]>; Sunila Sahu >> <[email protected]>; Ashish >> Gupta <[email protected]> >> 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
