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.guj...@intel.com>; Akhil Goyal
<akhil.go...@nxp.com>; Doherty, Declan <declan.dohe...@intel.com>; Jacob,
Jerin <jerin.jacobkollanukka...@cavium.com>
Cc: dev@dpdk.org; Vangati, Narender <narender.vang...@intel.com>; Rao,
Nikhil <nikhil....@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.go...@nxp.com>; Doherty, Declan
<declan.dohe...@intel.com>; De Lara Guarch, Pablo
<pablo.de.lara.gua...@intel.com>; Jacob, Jerin
<jerin.jacobkollanukka...@cavium.com>
Cc: dev@dpdk.org; Vangati, Narender <narender.vang...@intel.com>; Rao,
Nikhil <nikhil....@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
