Re: [dpdk-dev] [RFC] cryptodev/asymm: propose changes to modexp and modinv API

["Trahe, Fiona" <fiona.trahe@intel.com>]

Hi Shally, Arek,

> -----Original Message-----
> From: Kusztal, ArkadiuszX
> Sent: Monday, December 17, 2018 7:25 AM
> To: Verma, Shally <Shally.Verma@cavium.com>
> Cc: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Doherty, Declan
> <declan.doherty@intel.com>; Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>; Sunila Sahu
> <ssahu@marvell.com>; Kotamarthy, Kanaka <Kanaka.Kotamarthy@cavium.com>; Sahu, Sunila
> <Sunila.Sahu@cavium.com>; Cel, TomaszX <tomaszx.cel@intel.com>; Jozwiak, TomaszX
> <tomaszx.jozwiak@intel.com>
> Subject: RE: [RFC] cryptodev/asymm: propose changes to modexp and modinv API
> 
> >               rte_crypto_asym.h:233
> >                              rte_crypto_param modulus;
> >                              /**< modulus
> >                              * Prime modulus of the modexp transform operation in
> > octet-string
> >                              * network byte order format.
> >                              */
> >                              [AK] - Why prime? RSA for example use semi-prime or "RSA
> > multi-prime".
> >                              It should be just any positive integer.
> > [Shally] Hmm.. yes you're right . by the purpose of it , it is a semi-prime
> > input.. so prime shouldn't be mentioned here.
> [AK-v2] I think it could be any nonzero number even composite, for DH, DSA it would be prime etc.
> >                              [AK] - If session API layer should check if it is non-zero and
> > set flag accordingly.
> > [Shally] Sorry I didn't get this.. which flag you mean here? if modulus value 0
> > is passed, it should be considered as INVALID_PARAM.
> [AK-v2] - INVALID_PARAM is perfectly fine for me :).
[Fiona] About where the error checking should be done. 
In symmetric crypto the API layer doesn't do param checking it's up to the PMD.
But it seems, for asymm at least, like a good idea that the API layer checks for valid session
params, that way all PMDs benefit, rather than having multiple implementations do the same checks.
@Arek, I think that's what you're suggesting?
For op params I'm not so sure, the API layer probably shouldn't open up the op and should just pass to the 
PMD, to enable performance optimisation. The PMD generally does very little checking on the data-path
 - but I think for asymm at least divide-by-zero cases should be checked by the PMDs.