From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 0F00FA2F6B
	for <public@inbox.dpdk.org>; Tue,  8 Oct 2019 15:43:05 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id CB6281BFDD;
	Tue,  8 Oct 2019 15:43:03 +0200 (CEST)
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id CD2B51BFAB
 for <dev@dpdk.org>; Tue,  8 Oct 2019 15:43:01 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga003.jf.intel.com ([10.7.209.27])
 by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 08 Oct 2019 06:43:00 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.67,270,1566889200"; d="scan'208";a="196602270"
Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3])
 by orsmga003.jf.intel.com with ESMTP; 08 Oct 2019 06:42:59 -0700
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by
 IRSMSX108.ger.corp.intel.com ([169.254.11.26]) with mapi id 14.03.0439.000;
 Tue, 8 Oct 2019 14:42:58 +0100
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Zhang, Roy Fan" <roy.fan.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: "Doherty, Declan" <declan.doherty@intel.com>, "akhil.goyal@nxp.com"
 <akhil.goyal@nxp.com>
Thread-Topic: [PATCH v2 01/10] security: introduce CPU Crypto action type
 and API
Thread-Index: AQHVfSxmUj0sMRcnO0akMTIiljcfIqdQwUyQ
Date: Tue, 8 Oct 2019 13:42:57 +0000
Message-ID: <2601191342CEEE43887BDE71AB97725801919729E5@irsmsx105.ger.corp.intel.com>
References: <20190906131330.40185-1-roy.fan.zhang@intel.com>
 <20191007162850.60552-1-roy.fan.zhang@intel.com>
 <20191007162850.60552-2-roy.fan.zhang@intel.com>
In-Reply-To: <20191007162850.60552-2-roy.fan.zhang@intel.com>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDVhYmNlY2QtZmNhMS00NDIyLWJhMTgtMmRhOTEyNTAxMjczIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibnloeEdhVkx2cmE0aW8zTDFwYUJCVnJYZ1M0STVVK1YzZkhaNkIrbVRRbEJrSytqU0NwdjRabVh0UWE4Q0ZSciJ9
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [163.33.239.181]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v2 01/10] security: introduce CPU Crypto
 action type and API
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Fan,

>=20
> This patch introduce new RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO action type =
to
> security library. The type represents performing crypto operation with CP=
U
> cycles. The patch also includes a new API to process crypto operations in
> bulk and the function pointers for PMDs.
>=20
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> ---
>  lib/librte_security/rte_security.c           | 11 ++++++
>  lib/librte_security/rte_security.h           | 53 ++++++++++++++++++++++=
+++++-
>  lib/librte_security/rte_security_driver.h    | 22 ++++++++++++
>  lib/librte_security/rte_security_version.map |  1 +
>  4 files changed, 86 insertions(+), 1 deletion(-)
>=20
> diff --git a/lib/librte_security/rte_security.c b/lib/librte_security/rte=
_security.c
> index bc81ce15d..cdd1ee6af 100644
> --- a/lib/librte_security/rte_security.c
> +++ b/lib/librte_security/rte_security.c
> @@ -141,3 +141,14 @@ rte_security_capability_get(struct rte_security_ctx =
*instance,
>=20
>  	return NULL;
>  }
> +
> +int
> +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)
> +{
> +	RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->process_cpu_crypto_bulk, -1);
> +	return 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 aaafdfcd7..0caf5d697 100644
> --- a/lib/librte_security/rte_security.h
> +++ b/lib/librte_security/rte_security.h
> @@ -18,6 +18,7 @@ extern "C" {
>  #endif
>=20
>  #include <sys/types.h>
> +#include <sys/uio.h>
>=20
>  #include <netinet/in.h>
>  #include <netinet/ip.h>
> @@ -289,6 +290,20 @@ struct rte_security_pdcp_xform {
>  	uint32_t hfn_ovrd;
>  };
>=20
> +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.
>   */
> @@ -303,10 +318,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
> +	 */
>  };
>=20
>  /** Security session protocol definition */
> @@ -332,6 +351,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;
> @@ -665,6 +685,37 @@ const struct rte_security_capability *
>  rte_security_capability_get(struct rte_security_ctx *instance,
>  			    struct rte_security_capability_idx *idx);
>=20
> +/**
> + * Security vector structure, contains pointer to vector array and the l=
ength
> + * of the array
> + */
> +struct rte_security_vec {
> +	struct iovec *vec;
> +	uint32_t num;
> +};
> +
> +/**
> + * 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
> + * @return
> + *  - On success, 0
> + *  - On any failure, -1

I think it is much better to retrun number of successfully process entries
(or number of failed entries - whatever is your preference).
Then user can easily determine does he need to walk through status
(and if yes till what point) or not at all.
Sorry if I wasn't clear in my previous comment.

> + */
> +__rte_experimental
> +int
> +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);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/librte_security/rte_security_driver.h b/lib/librte_secur=
ity/rte_security_driver.h
> index 1b561f852..fe940fffa 100644
> --- a/lib/librte_security/rte_security_driver.h
> +++ b/lib/librte_security/rte_security_driver.h
> @@ -132,6 +132,26 @@ typedef int (*security_get_userdata_t)(void *device,
>  typedef const struct rte_security_capability *(*security_capabilities_ge=
t_t)(
>  		void *device);
>=20
> +/**
> + * Process security operations in bulk using CPU accelerated method.
> + *
> + * @param	sess		Security session structure.
> + * @param	buf		Buffer to the vectors to be processed.
> + * @param	iv		IV pointers.
> + * @param	aad		AAD pointers.
> + * @param	digest		Digest pointers.
> + * @param	status		Array of status value.
> + * @param	num		Number of elements in each array.
> + * @return
> + *  - On success, 0
> + *  - On any failure, -1
> + */
> +
> +typedef int (*security_process_cpu_crypto_bulk_t)(
> +		struct rte_security_session *sess,
> +		struct rte_security_vec buf[], void *iv[], void *aad[],
> +		void *digest[], int status[], uint32_t num);
> +
>  /** Security operations function pointer table */
>  struct rte_security_ops {
>  	security_session_create_t session_create;
> @@ -150,6 +170,8 @@ struct rte_security_ops {
>  	/**< Get userdata associated with session which processed the packet. *=
/
>  	security_capabilities_get_t capabilities_get;
>  	/**< Get security capabilities. */
> +	security_process_cpu_crypto_bulk_t process_cpu_crypto_bulk;
> +	/**< Process data in bulk. */
>  };
>=20
>  #ifdef __cplusplus
> diff --git a/lib/librte_security/rte_security_version.map b/lib/librte_se=
curity/rte_security_version.map
> index 53267bf3c..2132e7a00 100644
> --- a/lib/librte_security/rte_security_version.map
> +++ b/lib/librte_security/rte_security_version.map
> @@ -18,4 +18,5 @@ EXPERIMENTAL {
>  	rte_security_get_userdata;
>  	rte_security_session_stats_get;
>  	rte_security_session_update;
> +	rte_security_process_cpu_crypto_bulk;
>  };
> --
> 2.14.5