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

[Akhil Goyal <akhil.goyal@nxp.com>]

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@intel.com>; Akhil Goyal
>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; Jacob,
>> Jerin <Jerin.JacobKollanukkaran@cavium.com>
>> Cc: dev@dpdk.org; Vangati, Narender <narender.vangati@intel.com>; Rao,
>> Nikhil <nikhil.rao@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@nxp.com>; Doherty, Declan
>>> <declan.doherty@intel.com>; De Lara Guarch, Pablo
>>> <pablo.de.lara.guarch@intel.com>; Jacob, Jerin
>>> <Jerin.JacobKollanukkaran@cavium.com>
>>> Cc: dev@dpdk.org; Vangati, Narender <narender.vangati@intel.com>; Rao,
>>> Nikhil <nikhil.rao@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.
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.

IMO, private data offset in session is a better approach instead of 
adding one more enum. Others can suggest.

-Akhil
>>
>> Pablo
> Abhinandan
>