[dpdk-dev] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless

Shally Verma shallyv at marvell.com
Sun Jun 30 10:37:13 CEST 2019



> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe at intel.com>
> Sent: Friday, June 28, 2019 10:58 PM
> To: Shally Verma <shallyv at marvell.com>; Akhil Goyal <akhil.goyal at nxp.com>;
> Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>; dev at dpdk.org
> Cc: Trahe, Fiona <fiona.trahe at intel.com>
> Subject: [EXT] RE: [PATCH] cryptodev: extend api of asymmetric crypto by
> sessionless
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi Shally,
....

> > >
> >
> > [Shally]  I would favor to have feature flag instead, to keep it simple.
> > We're relying too much on documentation here. Any op status, be it
> > INVALID_OP_SESSION, or NOT_SUPPORTED does not give clear reason for
> > failure. Assuming we agree on feature flag, then next question comes
> > if PMD set SESSIONLESS feature flag, then does that mean it support
> > *only* sessionless OR both "session" and "sessionless" ?
> > To solve this, we can define it like this:
> > 1. if PMD does not set _SESSIONLESS feature flag, that implicitly mean
> > it support session based only (which is current case) 2. if PMD does
> > set _SESSIONLESS feature flag, then app can certainly use sessionless,
> > but if it invokes session init API, then
> >   - if PMD don't have session support, it should return NOT_SUPPORTED in
> session_init()
> >   - if PMD do have session support (which will be our case), then it
> > will allow session APIs. Then its app discretion to choose either of
> > these
> >
> > Does this sounds okay?
> >
> > Thanks
> > Shally
> [Fiona] Yes, this is ok for me.
> Or to paraphrase:
> sessionless feature flag just informs about sessionless.
> The response to session_init() informs whether sessions are supported or not.
>
That sounds perfect. So, we will have v2 for this? 

Thanks
Shally
 


More information about the dev mailing list