>-----Original Message-----
>From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com]
>Sent: 26 June 2018 03:04
>To: Verma, Shally <shally.ve...@cavium.com>
>Cc: Trahe, Fiona <fiona.tr...@intel.com>; akhil.go...@nxp.com; dev@dpdk.org;
>Athreya, Narayana Prasad
><narayanaprasad.athr...@cavium.com>; Sahu, Sunila <sunila.s...@cavium.com>;
>Gupta, Ashish <ashish.gu...@cavium.com>
>Subject: RE: [PATCH v3 1/6] lib/cryptodev: add asymmetric algos in cryptodev
>
>External Email
>
>Hi Shally,
>
>> -----Original Message-----
>> From: Verma, Shally [mailto:shally.ve...@cavium.com]
>> Sent: Friday, June 22, 2018 4:39 PM
>> To: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>
>> Cc: Trahe, Fiona <fiona.tr...@intel.com>; akhil.go...@nxp.com;
>> dev@dpdk.org; Athreya, Narayana Prasad
>> <narayanaprasad.athr...@cavium.com>; Sahu, Sunila
>> <sunila.s...@cavium.com>; Gupta, Ashish <ashish.gu...@cavium.com>
>> Subject: RE: [PATCH v3 1/6] lib/cryptodev: add asymmetric algos in cryptodev
>>
>> Hi Pablo
>>
>> >-----Original Message-----
>> >From: De Lara Guarch, Pablo [mailto:pablo.de.lara.gua...@intel.com]
>> >Sent: 15 June 2018 14:10
>> >To: Verma, Shally <shally.ve...@cavium.com>
>> >Cc: Trahe, Fiona <fiona.tr...@intel.com>; akhil.go...@nxp.com;
>> >dev@dpdk.org; Athreya, Narayana Prasad
>> ><narayanaprasad.athr...@cavium.com>; Sahu, Sunila
>> ><sunila.s...@cavium.com>; Gupta, Ashish <ashish.gu...@cavium.com>
>> >Subject: RE: [PATCH v3 1/6] lib/cryptodev: add asymmetric algos in
>> >cryptodev
>> >
>> //snip
>>
>> >
>> >...
>> >
>> >> +/**
>> >> + * Asymmetric Cryptographic Operation.
>> >> + *
>> >> + * Structure describing asymmetric crypto operation params.
>> >> + *
>> >> + */
>> >> +struct rte_crypto_asym_op {
>> >> + struct rte_cryptodev_asym_session *session;
>> >> + /**< Handle for the initialised session context */
>> >> +
>> >
>> >Looking at the xform structure, it looks like a chain of xforms is possible.
>> >Looking at this union, this case wouldn't be possible, as only one item
>> >from the
>> union can be set.
>>
>> [Shally] xforms, which support chaining, would need to have op_type in their
>> respective xform struct.
>> Example struct rte_crypto_dh_xform, where app can chain Deffie-hellman
>> public and/or shared secret compute and DSA sign compute.
>>
>> +struct rte_crypto_dh_xform {
>> + enum rte_crypto_asym_op_type type;
>> + /**< Setup xform for key generate or shared secret compute */ and DSA
>> +xforms struct
>>
>> test_cryptodev_asym illustrates how to setup chained dh+dsa ops.
>
>Are you talking about test_dh_gen_kp? Because this is the only function
>where I see that there is a chain of xforms.
>In this case, both xforms are the same type (RTE_CRYPTO_ASYM_XFORM_DH),
>and the operation only sets parameters for rte_crypto_dh_op_param.
[Shally] Ya you right. Testapp illustrates chaining for dh public and private
key pair generation. Not DH followed by DSA.
Currently, DH key pair generation was only identified requirement for chaining,
so only that is illustrated. If other xforms are to be extended for chaining,
then respective struct might need modification based on exact requirement.
>I would expect that dh_op_param and dsa_op_param would need to be set, which
>couldn't be done.
[Shally] No change would be required in either. if app want to DSA sign data
using internally generated DH private key, then PMD input DH params and setup
DSA to use key generated by DH. In such case, since end operation is DSA_SIGN,
so app will enqueue only DSA op with op_type = DSA_SIGN and respective
dsa_op_param for processing.
>
>Thanks,
>Pablo
>
>>
>> Thanks
>> Shally
>>
>>
>> >
>> //snip
