DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shally Verma <shallyv@marvell.com>
To: Akhil Goyal <akhil.goyal@nxp.com>,
	Anoob Joseph <anoobj@marvell.com>,
	"Ayuj Verma" <ayverma@marvell.com>
Cc: "arkadiuszx.kusztal@intel.com" <arkadiuszx.kusztal@intel.com>,
	Sunila Sahu <ssahu@marvell.com>,
	Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Fiona Trahe <fiona.trahe@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1 0/2] declare crypto asym xform immutable
Date: Thu, 25 Jul 2019 11:35:13 +0000	[thread overview]
Message-ID: <BN6PR1801MB205250F038CE71F1B559F965ADC10@BN6PR1801MB2052.namprd18.prod.outlook.com> (raw)
In-Reply-To: <VE1PR04MB6639FC900CF8BE7493F4B6B1E6C10@VE1PR04MB6639.eurprd04.prod.outlook.com>

Hi Akhil

> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Thursday, July 25, 2019 4:58 PM
> To: Anoob Joseph <anoobj@marvell.com>; Shally Verma
> <shallyv@marvell.com>; Ayuj Verma <ayverma@marvell.com>
> Cc: arkadiuszx.kusztal@intel.com; Sunila Sahu <ssahu@marvell.com>; Kanaka
> Durga Kotamarthy <kkotamarthy@marvell.com>; dev@dpdk.org; Fiona
> Trahe <fiona.trahe@intel.com>
> Subject: RE: [PATCH v1 0/2] declare crypto asym xform immutable
> 
> Hi Anoob/Shally
> 
> > >
> > > Hi Ayuj,
> > >
> > > I believe there are couple of issues with this patch.
> > >
> > > Are these experimental APIs? I believe they were made stable this
> > > release and I'm not sure if it is a right practice to edit an API
> > > without deprecation notice after it is made stable. Especially now
> > > that RC2 is done. @Akhil, what is your take on this?
> > > [Shally] These are experimental still, hence no deprecation notice.
> > > We checked about it with Fiona, Akhil before.
> >
> > [Anoob] In the patch, the edited APIs doesn't have experimental tag. I
> > leave it to Akhil's judgement on this.
> >
> The API is experimental. Check the .map file.
> 
> But these kind of patches cannot go in 1908 release, as we have already
> tagged it for RC2.
> We need to defer this change for 19.11 release.
> 
[Shally] Well. Cant do anything if we have missed deadline here. Right now its up for feedback.
Meanwhile if we get any agreement and window gets open for nearest release, then please consider it.

> One more issue that I see in this patch. QAT also uses these APIs, so it shall
> also be modified along with openssl.
> 
[Shally] We assume QAT changes will be done by QAT maintainer, once they review and approve this change.

Thanks
Shally
> 
> > >
> > > I think, the approach here is wrong. If the lifetime of the session
> > > is expected to be only few packets, then session-less (which I
> > > believe is in the pipeline) would make more sense.
> > > [Shally] See my response further below on this.
> > >
> > > If the lifetime of the session is expected to be more than that,
> > > then having this feature/limitation would make application more
> > > complicated. Also, since one asymmetric session can hold both public
> > > & private keys, the implicit assumption would be, the session can be
> > > used for multiple kinds of operations. This change is in contradiction with
> that.
> > > [Shally] Why the contradiction here? There's no change in session
> > > usage from current version. Currently too, once keys are set on
> > > asymmetric session, they are used with multiple operations using
> > > that sessions, example - once RSA xform is set with keys, then one
> > > can perform sign/verify/enc/dec. So, I don't see any change in that
> > > notion with this proposal. All we are changing is, PMD which does
> > > not need to store keys in specific format (like openssl PMD), can
> > > just hold app buffer pointer till session-lifetime (eventually
> > > giving same effect as sessionless). It will help such PMDs to optimize their
> session setup time by avoiding unnecessary memcpy of keys buffers.
> >
> > [Anoob] Contradiction is in the sense of what is a session. Here we
> > are saying one session can have SIGN & VERIFY, but the lifetime  of
> > the session is assumed to be "short".
> >
> > >
> > > But my major concern is how this can lead to accidental errors.
> > > Making the argument as const will mean the API won't edit its
> > > contents. But if there is a pointer in that (key happens to be a
> > > pointer inside the xform), having const for xform will not help.
> > > This is my understanding. Please correct me if I'm wrong.
> > > [Shally] This spec says " xform and its buffers remain constant" .
> > > So, intention is to state to apps that buffer passed to xform should
> > > be const in nature and that they should not modify it.
> >
> > [Anoob] The current change could break existing applications. And the
> > compiler will not be able to detect it.
> >
> > >
> > > Also, I could have the xform allocated from stack (non const,
> > > regular local
> > > variable) and then call the session_init. Would compiler throw an
> > > issue in that case? I doubt so.
> > >
> > > void abc(const int t)
> > > {
> > >         printf("%d\n", t);
> > > }
> > >
> > > void main()
> > > {
> > >         int t = 0;
> > >         abc(t);
> > >         t = 2;
> > >         abc(t);
> > > }
> > >
> > > To summarize, if this assumption is accepted, then compiler will not
> > > be able to ensure it. And to properly use it, application will have
> > > to be drafted differently. And when similar effect can be achieved
> > > by having session-less, this seems redundant.
> > > [Shally]  Compiler may or may not warn on typecast error here.
> >
> > [Anoob] May or may not be?
> >
> > > That's why
> > > spec and documentation are put in place to ensure that application
> > > don't reuse them or destroy them once "xform and its buffers" are set on
> session.
> > > And, same will need to be documented about xform for session-less
> > > usage as well.
> >
> > [Anoob] Can you describe how this is required in session-less?
> >
> > > Even there, we would ensure that application do not re-use or modify
> > > xform and its buffers until dequeue happen. So, practically I see,
> > > application would have to take of these cases in session-less as well.
> > >
> > > Since in session-based case, xform are set on it than ops, so we're
> > > moving same definition on session. So for PMDs which support
> > > sessions-based implementations ( like ours) , believe it completely
> > > make sense to enable sessions to have sessionless effect.  If we
> > > don't change spec to enable optimization, then we're making
> > > 1-approach slower than other.  PMDs can adopt any approach more
> > > suitable to them. But spec could be made flexible to allow them to
> > > experiment with both approaches for performance. Else , PMDs will be
> > > forced to experiment around sessionless which may be eventually be an
> unnecessary overhead for them.
> >
> > [Anoob] I get your intention on avoiding the memcpys. But the current
> > changes would make the spec more prone to errors. And if we think we
> > should improve the key handling done in both session & session-less, I
> > would suggest not to rush with this change. We can keep the API
> > experimental and continue improving it to fix this issue for all PMDs more
> cleanly.
> >
> > >
> > > Thanks
> > > Shally
> > >
> > > So this change is NACK from my side.
> > >
> > > Thanks,
> > > Anoob
> > >
> > > From: Ayuj Verma
> > > Sent: Wednesday, July 24, 2019 2:23 PM
> > > To: mailto:akhil.goyal@nxp.com
> > > Cc: mailto:arkadiuszx.kusztal@intel.com; Shally Verma
> > > <mailto:shallyv@marvell.com>; Sunila Sahu
> > > <mailto:ssahu@marvell.com>; Kanaka Durga Kotamarthy
> > > <mailto:kkotamarthy@marvell.com>; Anoob Joseph
> > > <mailto:anoobj@marvell.com>; mailto:dev@dpdk.org; Fiona Trahe
> > > <mailto:fiona.trahe@intel.com>
> > > Subject: Re: [PATCH v1 0/2] declare crypto asym xform immutable
> > >
> > > +Fiona.
> > > ________________________________________
> > > From: Ayuj Verma <mailto:ayverma@marvell.com>
> > > Sent: 24 July 2019 14:21:55
> > > To: mailto:akhil.goyal@nxp.com <mailto:akhil.goyal@nxp.com>
> > > Cc: mailto:arkadiuszx.kusztal@intel.com
> > > <mailto:arkadiuszx.kusztal@intel.com>; Shally Verma
> > > <mailto:shallyv@marvell.com>; Sunila Sahu
> > > <mailto:ssahu@marvell.com>; Kanaka Durga Kotamarthy
> > > <mailto:kkotamarthy@marvell.com>; Anoob Joseph
> > > <mailto:anoobj@marvell.com>; mailto:dev@dpdk.org
> > > <mailto:dev@dpdk.org>; Ayuj Verma <mailto:ayverma@marvell.com>
> > > Subject: [PATCH v1 0/2] declare crypto asym xform immutable
> > >
> > > Mark asym xform as immutable till lifetime of session. It will save
> > > session setup time for PMDs, which doesn't require any manipulation
> > > of xform data, by directly using these buffers.
> > >
> > > * Updated xform type in session init/configure
> > >   API as constant.
> > > * Updated doc with proper transform description.
> > > * Updated openssl PMD with above changes.
> > >
> > > Ayuj Verma (2):
> > >   lib/crypto: declare crypto asym xform immutable
> > >   crypto/openssl: mark asym xform constant
> > >
> > >  doc/guides/prog_guide/cryptodev_lib.rst      | 10 ++++++++++
> > >  drivers/crypto/openssl/rte_openssl_pmd_ops.c |  8 ++++----
> > >  lib/librte_cryptodev/rte_cryptodev.c         |  2 +-
> > >  lib/librte_cryptodev/rte_cryptodev.h         |  2 +-
> > >  lib/librte_cryptodev/rte_cryptodev_pmd.h     |  2 +-
> > >  5 files changed, 17 insertions(+), 7 deletions(-)
> > >
> > > --
> > > 1.8.3.1

  reply	other threads:[~2019-07-25 11:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24  8:51 Ayuj Verma
2019-07-24  8:51 ` [dpdk-dev] [PATCH v1 1/2] lib/crypto: " Ayuj Verma
2019-07-24  8:51 ` [dpdk-dev] [PATCH v1 2/2] crypto/openssl: mark asym xform constant Ayuj Verma
2019-07-24  8:52 ` [dpdk-dev] [PATCH v1 0/2] declare crypto asym xform immutable Ayuj Verma
2019-07-25  4:15   ` Anoob Joseph
2019-07-25  5:21     ` Shally Verma
2019-07-25  5:26       ` Anoob Joseph
2019-07-25  6:37       ` Anoob Joseph
2019-07-25  7:58         ` Shally Verma
2019-07-25 14:27           ` Kusztal, ArkadiuszX
2019-07-29 11:38             ` Ayuj Verma
2019-09-05  9:22               ` Kusztal, ArkadiuszX
2019-09-05 14:22                 ` Shally Verma
2019-09-06  6:08                   ` Anoob Joseph
2019-09-06 11:25                     ` Trahe, Fiona
2019-09-13 14:02                       ` Sunila Sahu
2019-09-13 14:59                         ` Kusztal, ArkadiuszX
2019-07-25 11:27         ` Akhil Goyal
2019-07-25 11:35           ` Shally Verma [this message]
2019-07-25 11:42             ` Akhil Goyal
2019-07-25 11:46               ` Shally Verma

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=BN6PR1801MB205250F038CE71F1B559F965ADC10@BN6PR1801MB2052.namprd18.prod.outlook.com \
    --to=shallyv@marvell.com \
    --cc=akhil.goyal@nxp.com \
    --cc=anoobj@marvell.com \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=ayverma@marvell.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=kkotamarthy@marvell.com \
    --cc=ssahu@marvell.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).