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

Akhil Goyal akhil.goyal at nxp.com
Wed Jan 17 11:52:50 CET 2018


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.
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
> 



More information about the dev mailing list