DPDK patches and discussions
 help / color / Atom feed
From: Hemant Agrawal <hemant.agrawal@nxp.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Doherty, Declan" <declan.doherty@intel.com>,
	Akhil Goyal <akhil.goyal@nxp.com>
Subject: Re: [dpdk-dev] [PATCH 01/10] security: introduce CPU Crypto action type and API
Date: Wed, 2 Oct 2019 02:47:09 +0000
Message-ID: <VI1PR0401MB254169BE7A81E52A0804E8C9899C0@VI1PR0401MB2541.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258019196F46F@irsmsx105.ger.corp.intel.com>

Hi Konstantin,

> > >>> This patch introduce new RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO
> > >>> action type to security library. The type represents performing
> > >>> crypto operation with CPU cycles. The patch also includes a new
> > >>> API to process crypto operations in bulk and the function pointers for
> PMDs.
> > >>>
> > >>> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> > >>> ---
> > >>>    lib/librte_security/rte_security.c           | 16 +++++++++
> > >>>    lib/librte_security/rte_security.h           | 51
> +++++++++++++++++++++++++++-
> > >>>    lib/librte_security/rte_security_driver.h    | 19 +++++++++++
> > >>>    lib/librte_security/rte_security_version.map |  1 +
> > >>>    4 files changed, 86 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/lib/librte_security/rte_security.c
> > >>> b/lib/librte_security/rte_security.c
> > >>> index bc81ce15d..0f85c1b59 100644
> > >>> --- a/lib/librte_security/rte_security.c
> > >>> +++ b/lib/librte_security/rte_security.c
> > >>> @@ -141,3 +141,19 @@ rte_security_capability_get(struct
> > >>> rte_security_ctx *instance,
> > >>>
> > >>>    	return NULL;
> > >>>    }
> > >>> +
> > >>> +void
> > >>> +rte_security_process_cpu_crypto_bulk(struct rte_security_ctx
> *instance,
> > >>> +		struct rte_security_session *sess,
> > >>> +		struct rte_security_vec buf[], void *iv[], void *aad[],
> > >>> +		void *digest[], int status[], uint32_t num) {
> > >>> +	uint32_t i;
> > >>> +
> > >>> +	for (i = 0; i < num; i++)
> > >>> +		status[i] = -1;
> > >>> +
> > >>> +	RTE_FUNC_PTR_OR_RET(*instance->ops->process_cpu_crypto_bulk);
> > >>> +	instance->ops->process_cpu_crypto_bulk(sess, buf, iv,
> > >>> +			aad, digest, status, num);
> > >>> +}
> > >>> diff --git a/lib/librte_security/rte_security.h
> > >>> b/lib/librte_security/rte_security.h
> > >>> index 96806e3a2..5a0f8901b 100644
> > >>> --- a/lib/librte_security/rte_security.h
> > >>> +++ b/lib/librte_security/rte_security.h
> > >>> @@ -18,6 +18,7 @@ extern "C" {
> > >>>    #endif
> > >>>
> > >>>    #include <sys/types.h>
> > >>> +#include <sys/uio.h>
> > >>>
> > >>>    #include <netinet/in.h>
> > >>>    #include <netinet/ip.h>
> > >>> @@ -272,6 +273,20 @@ struct rte_security_pdcp_xform {
> > >>>    	uint32_t hfn_threshold;
> > >>>    };
> > >>>
> > >>> +struct rte_security_cpu_crypto_xform {
> > >>> +	/** For cipher/authentication crypto operation the authentication
> may
> > >>> +	 * cover more content then the cipher. E.g., for IPSec ESP encryption
> > >>> +	 * with AES-CBC and SHA1-HMAC, the encryption happens after the
> ESP
> > >>> +	 * header but whole packet (apart from MAC header) is
> authenticated.
> > >>> +	 * The cipher_offset field is used to deduct the cipher data pointer
> > >>> +	 * from the buffer to be processed.
> > >>> +	 *
> > >>> +	 * NOTE this parameter shall be ignored by AEAD algorithms, since it
> > >>> +	 * uses the same offset for cipher and authentication.
> > >>> +	 */
> > >>> +	int32_t cipher_offset;
> > >>> +};
> > >>> +
> > >>>    /**
> > >>>     * Security session action type.
> > >>>     */
> > >>> @@ -286,10 +301,14 @@ enum rte_security_session_action_type {
> > >>>    	/**< All security protocol processing is performed inline during
> > >>>    	 * transmission
> > >>>    	 */
> > >>> -	RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
> > >>> +	RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
> > >>>    	/**< All security protocol processing including crypto is performed
> > >>>    	 * on a lookaside accelerator
> > >>>    	 */
> > >>> +	RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO
> > >>> +	/**< Crypto processing for security protocol is processed by CPU
> > >>> +	 * synchronously
> > >>> +	 */
> > >> though you are naming it cpu crypto, but it is more like raw packet
> > >> crypto, where you want to skip mbuf/crypto ops and directly wants
> > >> to work on raw buffer.
> > > Yes, but we do wat to do that (skip mbuf/crypto ops and use raw
> > > buffer), because this API is destined for SW backed implementation.
> > > For that case crypto-ops , mbuf, enqueue/dequeue are just unnecessary
> overhead.
> > I agree, we are also planning to take advantage of it for some
> > specific use-cases in future.
> > >>>    };
> > >>>
> > >>>    /** Security session protocol definition */ @@ -315,6 +334,7 @@
> > >>> struct rte_security_session_conf {
> > >>>    		struct rte_security_ipsec_xform ipsec;
> > >>>    		struct rte_security_macsec_xform macsec;
> > >>>    		struct rte_security_pdcp_xform pdcp;
> > >>> +		struct rte_security_cpu_crypto_xform cpucrypto;
> > >>>    	};
> > >>>    	/**< Configuration parameters for security session */
> > >>>    	struct rte_crypto_sym_xform *crypto_xform; @@ -639,6 +659,35
> > >>> @@ const struct rte_security_capability *
> > >>>    rte_security_capability_get(struct rte_security_ctx *instance,
> > >>>    			    struct rte_security_capability_idx *idx);
> > >>>
> > >>> +/**
> > >>> + * Security vector structure, contains pointer to vector array
> > >>> +and the length
> > >>> + * of the array
> > >>> + */
> > >>> +struct rte_security_vec {
> > >>> +	struct iovec *vec;
> > >>> +	uint32_t num;
> > >>> +};
> > >>> +
> > >> Just wondering if you want to change it to *in_vec and *out_vec,
> > >> that will be helpful in future, if the out-of-place processing is
> > >> required for CPU usecase as well?
> > > I suppose this is doable, though right now we don't plan to support such
> model.
> > They will come handy in future. I plan to use it in future and we can
> > skip the API/ABI breakage, if the placeholder are present
> > >
> > >>> +/**
> > >>> + * Processing bulk crypto workload with CPU
> > >>> + *
> > >>> + * @param	instance	security instance.
> > >>> + * @param	sess		security session
> > >>> + * @param	buf		array of buffer SGL vectors
> > >>> + * @param	iv		array of IV pointers
> > >>> + * @param	aad		array of AAD pointers
> > >>> + * @param	digest		array of digest pointers
> > >>> + * @param	status		array of status for the function to
> return
> > >>> + * @param	num		number of elements in each array
> > >>> + *
> > >>> + */
> > >>> +__rte_experimental
> > >>> +void
> > >>> +rte_security_process_cpu_crypto_bulk(struct rte_security_ctx
> *instance,
> > >>> +		struct rte_security_session *sess,
> > >>> +		struct rte_security_vec buf[], void *iv[], void *aad[],
> > >>> +		void *digest[], int status[], uint32_t num);
> > >>> +
> > >> Why not make the return as int, to indicate whether this API
> > >> completely failed or processed or have some valid status to look into?
> > > Good point, will change as suggested.
> >
> > I have another suggestions w.r.t iv, aad, digest etc. Why not put them
> > in a structure, so that you will
> >
> > be able to add/remove the variable without breaking the API prototype.
> 
> 
> Just to confirm, you are talking about something like:
> 
> struct rte_security_vec {
>    struct iovec *vec;
>    uint32_t num;
> };

[Hemant] My idea is:
 struct rte_security_vec {
    struct iovec *vec;
    struct iovec *out_vec;
    uint32_t num_in;
    uint32_t num_out; 
};

> 
> struct rte_security_sym_vec {
>       struct rte_security_vec buf;
>       void *iv;
>       void *aad;
>       void *digest;
> };
> 
[Hemant]  or leave the rte_security_vec altogether and make it part of rte_security_sym_vec itself.

> rte_security_process_cpu_crypto_bulk(struct rte_security_ctx *instance,
> 	struct rte_security_session *sess, struct rte_security_sym_vec buf[],
>                int status[], uint32_t num);
> 
> ?
> We thought about such way, though for PMD it would be more plausible to
> have same type of params grouped together, i.e. void *in[], void *out[], void
> *digest[], ...
> Another thing - above grouping wouldn't help to avoid ABI breakage, in case
> we'll need to add new field into rte_security_sym_vec (though it might help
> to avoid API breakage).
> 
> In theory other way is also possible:
> struct rte_security_sym_vec {
>       struct rte_security_vec *buf;
>       void **iv;
>       void **aad;
>       void **digest;
> };
> 
> rte_security_process_cpu_crypto_bulk(struct rte_security_ctx *instance,
> 	struct rte_security_session *sess, struct rte_security_sym_vec *buf,
>                int status[], uint32_t num);
> 
> And that might help for both ABI and API stability, but it looks really weird
> that way (at least to me).

[Hemant] I am fine either way. 

> Also this API is experimental and I suppose needs to stay experimental for
> few releases before we are sure nothing important is missing, so probably
> API/ABI stability is not that high concern for it right now.
> 
> Konstantin
> 
> 

  reply index

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 15:40 [dpdk-dev] [RFC PATCH 0/9] security: add software synchronous crypto process Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API Fan Zhang
2019-09-04 10:32   ` Akhil Goyal
2019-09-04 13:06     ` Zhang, Roy Fan
2019-09-06  9:01       ` Akhil Goyal
2019-09-06 13:12         ` Zhang, Roy Fan
2019-09-10 11:25           ` Akhil Goyal
2019-09-11 13:01             ` Ananyev, Konstantin
2019-09-06 13:27         ` Ananyev, Konstantin
2019-09-10 10:44           ` Akhil Goyal
2019-09-11 12:29             ` Ananyev, Konstantin
2019-09-12 14:12               ` Akhil Goyal
2019-09-16 14:53                 ` Ananyev, Konstantin
2019-09-16 15:08                   ` Ananyev, Konstantin
2019-09-17  6:02                   ` Akhil Goyal
2019-09-18  7:44                     ` Ananyev, Konstantin
2019-09-25 18:24                       ` Ananyev, Konstantin
2019-09-27  9:26                         ` Akhil Goyal
2019-09-30 12:22                           ` Ananyev, Konstantin
2019-09-30 13:43                             ` Akhil Goyal
2019-10-01 14:49                               ` Ananyev, Konstantin
2019-10-03 13:24                                 ` Akhil Goyal
2019-10-07 12:53                                   ` Ananyev, Konstantin
2019-10-09  7:20                                     ` Akhil Goyal
2019-10-09 13:43                                       ` Ananyev, Konstantin
2019-10-11 13:23                                         ` Akhil Goyal
2019-10-13 23:07                                           ` Zhang, Roy Fan
2019-10-14 11:10                                             ` Ananyev, Konstantin
2019-10-15 15:02                                               ` Akhil Goyal
2019-10-16 13:04                                                 ` Ananyev, Konstantin
2019-10-15 15:00                                             ` Akhil Goyal
2019-10-16 22:07                                           ` Ananyev, Konstantin
2019-10-17 12:49                                             ` Ananyev, Konstantin
2019-10-18 13:17                                             ` Akhil Goyal
2019-10-21 13:47                                               ` Ananyev, Konstantin
2019-10-22 13:31                                                 ` Akhil Goyal
2019-10-22 17:44                                                   ` Ananyev, Konstantin
2019-10-22 22:21                                                     ` Ananyev, Konstantin
2019-10-23 10:05                                                     ` Akhil Goyal
2019-10-30 14:23                                                       ` Ananyev, Konstantin
2019-11-01 13:53                                                         ` Akhil Goyal
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 2/9] crypto/aesni_gcm: add rte_security handler Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 3/9] app/test: add security cpu crypto autotest Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 4/9] app/test: add security cpu crypto perftest Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 5/9] crypto/aesni_mb: add rte_security handler Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 6/9] app/test: add aesni_mb security cpu crypto autotest Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 7/9] app/test: add aesni_mb security cpu crypto perftest Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 8/9] ipsec: add rte_security cpu_crypto action support Fan Zhang
2019-09-03 15:40 ` [dpdk-dev] [RFC PATCH 9/9] examples/ipsec-secgw: add security " Fan Zhang
2019-09-06 13:13 ` [dpdk-dev] [PATCH 00/10] security: add software synchronous crypto process Fan Zhang
2019-09-06 13:13   ` [dpdk-dev] [PATCH 01/10] security: introduce CPU Crypto action type and API Fan Zhang
2019-09-18 12:45     ` Ananyev, Konstantin
2019-09-29  6:00     ` Hemant Agrawal
2019-09-29 16:59       ` Ananyev, Konstantin
2019-09-30  9:43         ` Hemant Agrawal
2019-10-01 15:27           ` Ananyev, Konstantin
2019-10-02  2:47             ` Hemant Agrawal [this message]
2019-09-06 13:13   ` [dpdk-dev] [PATCH 02/10] crypto/aesni_gcm: add rte_security handler Fan Zhang
2019-09-18 10:24     ` Ananyev, Konstantin
2019-09-06 13:13   ` [dpdk-dev] [PATCH 03/10] app/test: add security cpu crypto autotest Fan Zhang
2019-09-06 13:13   ` [dpdk-dev] [PATCH 04/10] app/test: add security cpu crypto perftest Fan Zhang
2019-09-06 13:13   ` [dpdk-dev] [PATCH 05/10] crypto/aesni_mb: add rte_security handler Fan Zhang
2019-09-18 15:20     ` Ananyev, Konstantin
2019-09-06 13:13   ` [dpdk-dev] [PATCH 06/10] app/test: add aesni_mb security cpu crypto autotest Fan Zhang
2019-09-06 13:13   ` [dpdk-dev] [PATCH 07/10] app/test: add aesni_mb security cpu crypto perftest Fan Zhang
2019-09-06 13:13   ` [dpdk-dev] [PATCH 08/10] ipsec: add rte_security cpu_crypto action support Fan Zhang
2019-09-26 23:20     ` Ananyev, Konstantin
2019-09-27 10:38     ` Ananyev, Konstantin
2019-09-06 13:13   ` [dpdk-dev] [PATCH 09/10] examples/ipsec-secgw: add security " Fan Zhang
2019-09-06 13:13   ` [dpdk-dev] [PATCH 10/10] doc: update security cpu process description Fan Zhang
2019-09-09 12:43   ` [dpdk-dev] [PATCH 00/10] security: add software synchronous crypto process Aaron Conole
2019-10-07 16:28   ` [dpdk-dev] [PATCH v2 " Fan Zhang
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 01/10] security: introduce CPU Crypto action type and API Fan Zhang
2019-10-08 13:42       ` Ananyev, Konstantin
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 02/10] crypto/aesni_gcm: add rte_security handler Fan Zhang
2019-10-08 13:44       ` Ananyev, Konstantin
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 03/10] app/test: add security cpu crypto autotest Fan Zhang
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 04/10] app/test: add security cpu crypto perftest Fan Zhang
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 05/10] crypto/aesni_mb: add rte_security handler Fan Zhang
2019-10-08 16:23       ` Ananyev, Konstantin
2019-10-09  8:29       ` Ananyev, Konstantin
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 06/10] app/test: add aesni_mb security cpu crypto autotest Fan Zhang
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 07/10] app/test: add aesni_mb security cpu crypto perftest Fan Zhang
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 08/10] ipsec: add rte_security cpu_crypto action support Fan Zhang
2019-10-08 23:28       ` Ananyev, Konstantin
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 09/10] examples/ipsec-secgw: add security " Fan Zhang
2019-10-07 16:28     ` [dpdk-dev] [PATCH v2 10/10] doc: update security cpu process description Fan Zhang

Reply instructions:

You may reply publically 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=VI1PR0401MB254169BE7A81E52A0804E8C9899C0@VI1PR0401MB2541.eurprd04.prod.outlook.com \
    --to=hemant.agrawal@nxp.com \
    --cc=akhil.goyal@nxp.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=roy.fan.zhang@intel.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

DPDK patches and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox