DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: Konstantin Ananyev <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"techboard@dpdk.org" <techboard@dpdk.org>
Cc: "roy.fan.zhang@intel.com" <roy.fan.zhang@intel.com>,
	"declan.doherty@intel.com" <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [RFC 3/4] cryptodev: introduce cpu-crypto API
Date: Tue, 5 Nov 2019 21:41:43 +0000	[thread overview]
Message-ID: <VE1PR04MB66395AD8E41C0EBF5ACD9496E67E0@VE1PR04MB6639.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20191105184122.15172-4-konstantin.ananyev@intel.com>

Hi Konstantin,

> 
> This patch extends rte_cryptodev API with CPU-CRYPTO mode.
> This is done by reusing existing rte_crypto_sym_session structure itself
> and related control-path cryptodev API (init/clear/get_size/etc.)
>  For data-path new sym_cpu_ process() function is added into
> rte_cryptodev dev_ops.
> 
> Crypto PMD that wants to support that functionality would need to:
> 1. claim RTE_CRYPTODEV_FF_SYM_CPU_CRYPTO capability supported.
> 2. change at least the following functions inside rte_cryptodev_ops:
> 	. sym_session_get_size,
> 	. sym_session_configure,
> 	. sym_session_clear
> to accommodate support for both sync and async modes,
> 3. implement new function inside rte_cryptodev_ops:
> 	sym_cpu_process
> 
> For data-path processing consumer of that API would have to maintain:
> 	struct rte_cryptodev_sym_session *sess,
> 	list of dev ids for which this session was properly initialized
> 
> As an advantage of this approach - reuse of existing API
> and minimal visible changes for crypto PMDs.
> 
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h    | 11 ++++++++++-
>  lib/librte_cryptodev/rte_cryptodev.c     | 14 ++++++++++++++
>  lib/librte_cryptodev/rte_cryptodev.h     | 24 ++++++++++++++++++++++++
>  lib/librte_cryptodev/rte_cryptodev_pmd.h | 22 ++++++++++++++++++++++
>  4 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index d8d9e9514..790c77524 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -166,6 +166,10 @@ struct rte_crypto_cipher_xform {
>  	 *  - Both keys must have the same size.
>  	 **/
> 
> +	/**
> +         * CPU-CRYPTO specific data, should be set properly when
> +	 * (xform->type & RTE_CRYPTO_SYM_CPU_CRYPTO) != 0, otherwise
> ignored.
> +	 */
>  	struct {
>  		/**
>  		 * offset for cipher to start within user provided data buffer.

Earlier I was ok to have this offset but on another thought, why do you need this?
User can give the exact pointer in the process() API from where he wants to do ciphering.
You will be adding this offset in the driver if you keep this in xform/session. So I think there is
no difference whether you add in the driver or the application. Am I missing something?

> @@ -415,6 +419,10 @@ struct rte_crypto_aead_xform {
>  		uint16_t length;	/**< key length in bytes */
>  	} __attribute__((__packed__)) key;
> 
> +	/**
> +         * CPU-CRYPTO specific data, should be set properly when
> +	 * (xform->type & RTE_CRYPTO_SYM_CPU_CRYPTO) != 0, otherwise
> ignored.
> +	 */
>  	struct {
>  		/**
>  		 * offset for cipher to start within user provided data buffer.
> @@ -471,7 +479,8 @@ enum rte_crypto_sym_xform_type {
>  	RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED = 0,	/**< No xform
> specified */
>  	RTE_CRYPTO_SYM_XFORM_AUTH,		/**< Authentication
> xform */
>  	RTE_CRYPTO_SYM_XFORM_CIPHER,		/**< Cipher xform  */
> -	RTE_CRYPTO_SYM_XFORM_AEAD		/**< AEAD xform  */
> +	RTE_CRYPTO_SYM_XFORM_AEAD,		/**< AEAD xform  */
> +	RTE_CRYPTO_SYM_CPU_CRYPTO = INT32_MIN,  /**< xform for cpu-
> crypto */

This is not a correct place to have this. All types of xforms CIPHER/AUTH/AEAD 
can be used in SYNC mode

>  };
> 
>  /**
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index 89aa2ed3e..b1dbaf4c1 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -1616,6 +1616,20 @@ rte_cryptodev_sym_session_get_user_data(
>  	return (void *)(sess->sess_data + sess->nb_drivers);
>  }
> 
> +__rte_experimental
> +int
> +rte_cryptodev_sym_cpu_crypto_process(uint8_t dev_id,
> +	struct rte_cryptodev_sym_session *sess, struct rte_crypto_sym_vec
> *vec,
> +	int32_t status[], uint32_t num)
> +{
> +	struct rte_cryptodev *dev;
> +
> +	dev = rte_cryptodev_pmd_get_dev(dev_id);
> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_cpu_process,-
> ENOTSUP);
> +
> +	return dev->dev_ops->sym_cpu_process(dev, sess, vec, status, num);
> +}
> +
>  /** Initialise rte_crypto_op mempool element */
>  static void
>  rte_crypto_op_init(struct rte_mempool *mempool,
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index c6ffa3b35..24877006c 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -450,6 +450,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> rte_crypto_asym_xform_type *xform_enum,
>  /**< Support encrypted-digest operations where digest is appended to data */
>  #define RTE_CRYPTODEV_FF_ASYM_SESSIONLESS		(1ULL << 20)
>  /**< Support asymmetric session-less operations */
> +#define	RTE_CRYPTODEV_FF_SYM_CPU_CRYPTO
> 	(1ULL << 21)
> +/**< Support symmeteric cpu-crypto processing */
> 
> 
>  /**
> @@ -1274,6 +1276,28 @@ void *
>  rte_cryptodev_sym_session_get_user_data(
>  					struct rte_cryptodev_sym_session
> *sess);
> 
> +/**
> + * Perform actual crypto processing (encrypt/digest or auth/decrypt)
> + * on user provided data.
> + *
> + * @param	dev_id	The device identifier.
> + * @param	sess	Cryptodev session structure
> + * @param	vec	Array of vectors for input data
> + * @param	status	Array of status values (one per vec)
> + *			(RTE_CRYPTO_OP_STATUS_* values)
> + * @param	num	Number of elems in vec and status arrays.
> + *
> + * @return
> + *  - Returns negative errno value on error, or non-negative number
> + *    of successfully processed input vectors.
> + *
> +*/
> +__rte_experimental
> +int
> +rte_cryptodev_sym_cpu_crypto_process(uint8_t dev_id,
> +	struct rte_cryptodev_sym_session *sess, struct rte_crypto_sym_vec
> *vec,
> +	int32_t status[], uint32_t num);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
> b/lib/librte_cryptodev/rte_cryptodev_pmd.h
> index fba14f2fa..02e7a19ae 100644
> --- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
> +++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
> @@ -308,6 +308,26 @@ typedef void (*cryptodev_sym_free_session_t)(struct
> rte_cryptodev *dev,
>   */
>  typedef void (*cryptodev_asym_free_session_t)(struct rte_cryptodev *dev,
>  		struct rte_cryptodev_asym_session *sess);
> +/**
> + * Perform actual crypto processing (encrypt/digest or auth/decrypt)
> + * on user provided data.
> + *
> + * @param	dev		Crypto device pointer
> + * @param	sess	Cryptodev session structure
> + * @param	vec	Array of vectors for input data
> + * @param	status	Array of status values (one per vec)
> + *			(RTE_CRYPTO_OP_STATUS_* values)
> + * @param	num	Number of elems in vec and status arrays.
> + *
> + * @return
> + *  - Returns negative errno value on error, or non-negative number
> + *    of successfully processed input vectors.
> + *
> +*/
> +typedef int (*cryptodev_sym_cpu_crypto_process_t)(struct rte_cryptodev *dev,
> +	struct rte_cryptodev_sym_session *sess, struct rte_crypto_sym_vec
> *vec,
> +	int32_t status[], uint32_t num);
> +
> 
>  /** Crypto device operations function pointer table */
>  struct rte_cryptodev_ops {
> @@ -342,6 +362,8 @@ struct rte_cryptodev_ops {
>  	/**< Clear a Crypto sessions private data. */
>  	cryptodev_asym_free_session_t asym_session_clear;
>  	/**< Clear a Crypto sessions private data. */
> +	cryptodev_sym_cpu_crypto_process_t sym_cpu_process;
> +	/**< process input data synchronously (cpu-crypto). */
>  };
> 
> 
> --
> 2.17.1


  reply	other threads:[~2019-11-05 21:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 18:41 [dpdk-dev] [RFC 0/4] cpu-crypto API choices Konstantin Ananyev
2019-11-05 18:41 ` [dpdk-dev] [RFC 1/4] cpu-crypto: Introduce basic data structures Konstantin Ananyev
2019-11-05 18:41 ` [dpdk-dev] [RFC 2/4] security: introduce cpu-crypto API Konstantin Ananyev
2019-11-05 18:41 ` [dpdk-dev] [RFC 3/4] cryptodev: " Konstantin Ananyev
2019-11-05 21:41   ` Akhil Goyal [this message]
2019-11-06 14:49     ` Ananyev, Konstantin
2019-11-05 18:41 ` [dpdk-dev] [RFC 4/4] cryptodev: introduce rte_crypto_cpu_sym_session API Konstantin Ananyev
2019-11-06  4:54 ` [dpdk-dev] [dpdk-techboard] [RFC 0/4] cpu-crypto API choices Honnappa Nagarahalli
2019-11-06  9:35   ` Thomas Monjalon
2019-11-06  9:48     ` Thomas Monjalon
2019-11-06 10:14       ` Ananyev, Konstantin
2019-11-06 11:33         ` Ananyev, Konstantin
2019-11-06 12:18           ` Thomas Monjalon
2019-11-06 12:22             ` Hemant Agrawal
2019-11-06 15:19             ` Ananyev, Konstantin
2019-11-14  5:46 ` [dpdk-dev] " Jerin Jacob
2019-11-18 11:57   ` Ananyev, Konstantin
2019-11-20 14:27     ` Jerin Jacob

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=VE1PR04MB66395AD8E41C0EBF5ACD9496E67E0@VE1PR04MB6639.eurprd04.prod.outlook.com \
    --to=akhil.goyal@nxp.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=techboard@dpdk.org \
    /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).