[dpdk-dev] [PATCH 1/2] lib/cryptodev: add support to set session private data

[Gujjar, Abhinandan S]

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal at nxp.com]
> Sent: Wednesday, January 17, 2018 4:23 PM
> To: Gujjar, Abhinandan S <abhinandan.gujjar at intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch at intel.com>; Doherty, Declan
> <declan.doherty at intel.com>; Jacob, Jerin
> <Jerin.JacobKollanukkaran at cavium.com>
> Cc: dev at dpdk.org; Vangati, Narender <narender.vangati at intel.com>; Rao,
> Nikhil <nikhil.rao at intel.com>
> Subject: Re: [PATCH 1/2] lib/cryptodev: add support to set session private data
> 
> Hi Abhinandan,
> On 1/17/2018 3:35 PM, Gujjar, Abhinandan S wrote:
> > Hi Akhil,
> >
> >> -----Original Message-----
> >> From: De Lara Guarch, Pablo
> >> Sent: Wednesday, January 17, 2018 3:16 PM
> >> To: Gujjar, Abhinandan S <abhinandan.gujjar at intel.com>; Akhil Goyal
> >> <akhil.goyal at nxp.com>; Doherty, Declan <declan.doherty at intel.com>;
> >> Jacob, Jerin <Jerin.JacobKollanukkaran at cavium.com>
> >> Cc: dev at dpdk.org; Vangati, Narender <narender.vangati at intel.com>;
> >> Rao, Nikhil <nikhil.rao at intel.com>
> >> Subject: RE: [PATCH 1/2] lib/cryptodev: add support to set session
> >> private data
> >>
> >> Hi Abhinandan,
> >>
> >>> -----Original Message-----
> >>> From: Gujjar, Abhinandan S
> >>> Sent: Wednesday, January 17, 2018 6:35 AM
> >>> To: Akhil Goyal <akhil.goyal at nxp.com>; Doherty, Declan
> >>> <declan.doherty at intel.com>; De Lara Guarch, Pablo
> >>> <pablo.de.lara.guarch at intel.com>; Jacob, Jerin
> >>> <Jerin.JacobKollanukkaran at cavium.com>
> >>> Cc: dev at dpdk.org; Vangati, Narender <narender.vangati at intel.com>;
> >>> Rao, Nikhil <nikhil.rao at intel.com>
> >>> Subject: RE: [PATCH 1/2] lib/cryptodev: add support to set session
> >>> private data
> >>>
> >>> Hi Akhil,
> >>>
> >>
> >> ...
> >>
> >>> I guess, you are suggesting below changes:
> >>> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> >>> b/lib/librte_cryptodev/rte_cryptodev.h
> >>> index 56958a6..057c39a 100644
> >>> --- a/lib/librte_cryptodev/rte_cryptodev.h
> >>> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> >>> @@ -892,6 +892,8 @@ struct rte_cryptodev_data {
> >>>
> >>>   /** Cryptodev symmetric crypto session */  struct
> >>> rte_cryptodev_sym_session {
> >>> +       uint16_t private_data_offset;
> >>> +       /**< Private data offset */
> >>>          __extension__ void *sess_private_data[0];
> >>>          /**< Private session material */  }; I am ok with this.
> >>>
> >>> Declan/Pablo,
> >>> Is this ok? Do you see any impact on performance or anything else
> >>> has to be considered?
> >>
> >> This is breaking ABI, and since there is a zero length array, this
> >> latter has to be at the end of the structure.
> >> Therefore, this is not a valid option unless ABI deprecation is
> >> announced and then it could be merged in the next release.
> > What is your opinion on this?
> > Should we consider retaining the enum rte_crypto_op_private_data_type?
> 
> As per our previous discussion we are anyway pushing crypto adapter to next
> release, then we do have time for the deprecation notice to be sent.
Not sure, it is really worth breaking ABI or have an enum.
> Or you can reserve the first byte of private data (internal to library) in the session
> to check whether the private data is valid or not.
Regarding reserving the first byte which validates the rest of the metadata data,
unless this byte is also included part of rte_cryptodev_sym_session_create()
i.e. 
memset(sess, 0, (sizeof(void *) * nb_drivers + private_data_flag));
and in
rte_cryptodev_get_header_session_size(void)
{
	/*
	 * Header contains pointers to the private data
	 * of all registered drivers
	 */
	return (sizeof(void *) * nb_drivers + private_data_flag);
}
Without above changes, the flag content can't be just trusted. Do you agree?

Pablo/Declan,
Hope the changes are ok? ABI breakage or anything has to be considered again?
> 
> IMO, private data offset in session is a better approach instead of adding one
> more enum. Others can suggest.
@Others, please provide your inputs so that I can prepare the next patch.

-Abhinandan
> 
> -Akhil
> >>
> >> Pablo
> > Abhinandan
> >