DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: Akhil Goyal <akhil.goyal@nxp.com>,
	"Kusztal, ArkadiuszX" <arkadiuszx.kusztal@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"shally.verma@caviumnetworks.com"
	<shally.verma@caviumnetworks.com>
Cc: "Trahe, Fiona" <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless
Date: Fri, 21 Jun 2019 14:18:25 +0000	[thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B435897A28B6@IRSMSX101.ger.corp.intel.com> (raw)
In-Reply-To: <VE1PR04MB663924D4D9425570E41215ADE6E70@VE1PR04MB6639.eurprd04.prod.outlook.com>

Hi Akhil,

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Friday, June 21, 2019 1:23 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>;
> dev@dpdk.org; shally.verma@caviumnetworks.com
> Subject: RE: [PATCH] cryptodev: extend api of asymmetric crypto by sessionless
> 
> Hi Fiona,
> 
> >
> > Hi Akhil, Arek, Shally,
> >
> > > -----Original Message-----
> > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> > > Sent: Thursday, June 20, 2019 3:17 PM
> > > To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > > Cc: Trahe, Fiona <fiona.trahe@intel.com>;
> > shally.verma@caviumnetworks.com
> > > Subject: RE: [PATCH] cryptodev: extend api of asymmetric crypto by
> > sessionless
> > > >
> > > > Asymmetric cryptography algorithms may more likely use
> > > > sessionless API so there is need to extend API.
> > > >
> > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > ---
> > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> >
> > [Fiona] The code is ok but I think a little more is needed.
> > As all PMDs don't support sessionless, this needs to be handled as an optional
> > capability.
> > And in future some PMDs may only support SESSIONLESS and some only support
> > WITH_SESSION.
> 
> 
> I believe this holds true for symmetric crypto as well. But adding a feature flag for everything may beat
> the purpose
> Of adding a feature flag. Sessionless crypto operations in symmetric crypto is being used without any
> issue for a long
> And nobody feel the need of that as of today. So my question is how asymmetric crypto pmds are
> different that they
> Need feature flag?
> 
> If the driver does not support sessionless, then it may give an error while creating it. I don't think that is
> an issue. It is
> Already being handled in the rte_crypto_op by an enum which denote that the 'op' need to be
> processed with some
> Session or with xform.
> 
> > So I propose adding 2 feature flags to the API
> > RTE_CRYPTODEV_FF_ASYM_WTH_SESSION
> > RTE_CRYPTODEV_FF_ASYM_SESSIONLESS
> > and including in this patch the PMD and UT changes to set and test the first flag.
[Fiona] symmetric crypto is inherently session-based, so all PMDs support this. I don't know how much real use SESSIONLESS actually gets.
For asymmetric, my understanding is that sessionless is more likely to be used. Sequences of ops using the same params/keys are an unlikely use-case, so there's no advantage to setting up a session and it's an extra API call so preferable to avoid.
That said, I think it would be ok with one feature flag.
If a PMD doesn't support WITH_SESSION, the session_init  API will fail with -ENOTSUP, so giving the app the information it needs. This can be documented as a PMD limitation and I'm ok with it not having a feature flag.
However if a PMD doesn't support SESSIONLESS, then the fail will only occur on the op_enqueue_burst. 
Failure to enqueue the next op is a typical outcome on a busy hardware device, and the app will likely assume the device is busy and try again with same result. The PMD could change the op.status to OP_STATUS_ERROR  or OP_INVALID_SESSION but it would still require the app to check the status of the next op which failed to enqueue. I think it better to detect this before the op_enqueue by providing a RTE_CRYPTODEV_FF_ASYM_SESSIONLESS feature flag.


> > We'll follow up with SESSIONLESS QAT implementation and UTs in a separate
> > patchset.
> > Also documentation updates should go with this API patch, i.e.
> >  - update section 16.7.2 in the cryptodev programmers guide - and review that
> > doc in case other sections need updating.
> Yes this needs to be updated if the implementation is complete and we have some PMD supporting
> that.
[Fiona] Are you saying we need to submit the PMD changes with this API patch? Or can we do
separately as we'd planned?

> 
> >  - fix comment in rte_crypto.h under STATUS_INVALID_SESSION
> >  - release note
> >
> >
> 
> 
> -Akhil

  reply	other threads:[~2019-06-21 14:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03 19:44 Arek Kusztal
2019-06-05 12:16 ` [dpdk-dev] [EXT] " Shally Verma
2019-06-14 10:21   ` Kusztal, ArkadiuszX
2019-06-14 10:24   ` Kusztal, ArkadiuszX
2019-06-14 11:23     ` Shally Verma
2019-06-14 12:12       ` Kusztal, ArkadiuszX
2019-06-20 14:17 ` [dpdk-dev] " Akhil Goyal
2019-06-21 11:58   ` Trahe, Fiona
2019-06-21 12:22     ` Akhil Goyal
2019-06-21 14:18       ` Trahe, Fiona [this message]
2019-06-24  7:05         ` Akhil Goyal
2019-06-27 11:54           ` Trahe, Fiona
2019-06-28 16:10             ` Shally Verma
2019-06-28 17:27               ` Trahe, Fiona
2019-06-30  8:37                 ` Shally Verma
2019-08-12  9:26 ` [dpdk-dev] [EXT] " Anoob Joseph
2019-08-12 10:00   ` Kusztal, ArkadiuszX

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=348A99DA5F5B7549AA880327E580B435897A28B6@IRSMSX101.ger.corp.intel.com \
    --to=fiona.trahe@intel.com \
    --cc=akhil.goyal@nxp.com \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=dev@dpdk.org \
    --cc=shally.verma@caviumnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).