> -----Original Message-----
> From: Trahe, Fiona <fiona.tr...@intel.com>
> Sent: Friday, June 28, 2019 10:58 PM
> To: Shally Verma <shal...@marvell.com>; Akhil Goyal <akhil.go...@nxp.com>;
> Kusztal, ArkadiuszX <arkadiuszx.kusz...@intel.com>; dev@dpdk.org
> Cc: Trahe, Fiona <fiona.tr...@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
