DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anoob Joseph <anoobj@marvell.com>
To: Shally Verma <shallyv@marvell.com>,
	Ayuj Verma <ayverma@marvell.com>,
	"akhil.goyal@nxp.com" <akhil.goyal@nxp.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 05:26:07 +0000	[thread overview]
Message-ID: <MN2PR18MB28779DF33A913845911DDB00DFC10@MN2PR18MB2877.namprd18.prod.outlook.com> (raw)
In-Reply-To: <BN6PR1801MB2052BB8122443EEF2A0CE33EADC10@BN6PR1801MB2052.namprd18.prod.outlook.com>

Hi Shally,

Oh yeah! Should've noticed. My settings is to use the incoming mail's formatting. Mail Ayuj created the issue.

Thanks,
Anoob

> -----Original Message-----
> From: Shally Verma
> Sent: Thursday, July 25, 2019 10:52 AM
> To: Anoob Joseph <anoobj@marvell.com>; Ayuj Verma
> <ayverma@marvell.com>; akhil.goyal@nxp.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
> 
> Seems your reply is not in plaintext which will make it difficult for inline
> response. So, please take care of that when you reply.
> Rest, please see my response inline.
> 
> From: Anoob Joseph
> Sent: Thursday, July 25, 2019 9:46 AM
> To: Ayuj Verma <ayverma@marvell.com>; akhil.goyal@nxp.com
> Cc: arkadiuszx.kusztal@intel.com; Shally Verma <shallyv@marvell.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 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.
> 
> 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.
> 
> 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.
> 
> 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. 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.
> 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.
> 
> 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  5:26 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 [this message]
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
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=MN2PR18MB28779DF33A913845911DDB00DFC10@MN2PR18MB2877.namprd18.prod.outlook.com \
    --to=anoobj@marvell.com \
    --cc=akhil.goyal@nxp.com \
    --cc=arkadiuszx.kusztal@intel.com \
    --cc=ayverma@marvell.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=kkotamarthy@marvell.com \
    --cc=shallyv@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).