DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anoob Joseph <anoobj@marvell.com>
To: Matan Azrad <matan@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Declan Doherty <declan.doherty@intel.com>,
	Somalapuram Amaranath <asomalap@amd.com>,
	Ruifeng Wang <ruifeng.wang@arm.com>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Fan Zhang <roy.fan.zhang@intel.com>,
	"John Griffin" <john.griffin@intel.com>,
	Pablo de Lara <pablo.de.lara.guarch@intel.com>,
	Michael Shamis <michaelsh@marvell.com>,
	Nagadheeraj Rottela <rnagadheeraj@marvell.com>,
	Ankur Dwivedi <adwivedi@marvell.com>,
	Gagandeep Singh <g.singh@nxp.com>,
	Jay Zhou <jianjay.zhou@huawei.com>,
	Akhil Goyal <gakhil@marvell.com>,
	"Jerin Jacob Kollanukkaran" <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher block sizes
Date: Fri, 26 Feb 2021 05:01:15 +0000	[thread overview]
Message-ID: <MWHPR18MB11682C7E16206EDF52F1AACBDF9D9@MWHPR18MB1168.namprd18.prod.outlook.com> (raw)
In-Reply-To: <1612449252-395208-1-git-send-email-matan@nvidia.com>

Hi Matan,

With the current spec, AES-XTS operation offloading would mean application is expected to track data blocks and the corresponding tweak & cipher stealing, while the final crypto operation gets offloaded to PMD. This proposal aims at moving the entire AES-XTS operation (including tweak update) to PMD. Did I understand the proposal right?

If yes, I believe this is a good feature to be added. But I've few questions,

1. Who is responsible for cipher stealing? Do we expect PMD to pad the final data unit?
2. If we treat AES-XTS as an operation for just encrypting and decrypting a large blob of data, the current proposal would be good enough. But often, AES-XTS is used in disk encryption where selected pages are updated without requiring the entire disk to be decrypted (& encrypted after). Did you consider if we could extend the spec to support such a use case also? (Agreed that we could do page updates by handling tweak etc from application as is being done now).
3. On top level, this requirement has similarities to rte_security. Did you consider that route?

Thanks,
Anoob

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Thursday, February 4, 2021 8:04 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Declan Doherty <declan.doherty@intel.com>;
> Somalapuram Amaranath <asomalap@amd.com>; Ruifeng Wang
> <ruifeng.wang@arm.com>; Ajit Khaparde <ajit.khaparde@broadcom.com>;
> Anoob Joseph <anoobj@marvell.com>; Fan Zhang
> <roy.fan.zhang@intel.com>; John Griffin <john.griffin@intel.com>; Pablo de
> Lara <pablo.de.lara.guarch@intel.com>; Michael Shamis
> <michaelsh@marvell.com>; Nagadheeraj Rottela
> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> Gagandeep Singh <g.singh@nxp.com>; Jay Zhou
> <jianjay.zhou@huawei.com>
> Subject: [EXT] [PATCH] cryptodev: support multiple cipher block sizes
> 
> External Email
> 
> ----------------------------------------------------------------------
> In cryptography, a block cipher is a deterministic algorithm operating on
> fixed-length groups of bits, called blocks.
> 
> A block cipher consists of two paired algorithms, one for encryption and the
> other for decryption. Both algorithms accept two inputs:
> an input block of size n bits and a key of size k bits; and both yield an n-bit
> output block. The decryption algorithm is defined to be the inverse function
> of the encryption.
> 
> Some cipher algorithms support multiple block sizes, e.g. AES-XTS supports
> any block size in range [16B, 2^24B], in this case, A plain-text data, divided
> into N amount of n-bits blocks, which is encrypted to the same data size,
> cipher-text, must be decrypted in the same division of N amount of n-bits
> blocks in order to get the same plain-text data.
> 
> The current cryptodev API doesn't allow the user to select a specific block
> size supported by the devices In addition, there is no definition how the IV is
> detected per block when single operation includes more than one block.
> 
> That causes applications to use single operation per block even though all the
> data is continuous in memory what reduces datapath performance.
> 
> Add a new feature flag to support multiple block sizes, called
> RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS.
> Add a new field in cipher capability, called bsf - block size flags, where the
> devices can report the range of the supported block sizes.
> Add a new cipher transformation field, called block_size, where the user can
> select one block size from the supported range.
> 
> All the new fields do not change the size of their structures.
> 
> Using flags to report the supported block sizes capability allows the devices
> to report a range simply as same as the user to read it simply.
> Also, thus sizes are usually common and probably will be shared between the
> devices.
> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h | 12 ++++++++++++
> lib/librte_cryptodev/rte_cryptodev.h  | 23 ++++++++++++++++++++++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 9d572ec..9a1215d 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -265,6 +265,18 @@ struct rte_crypto_cipher_xform {
>  		 * which can be in the range 7 to 13 inclusive.
>  		 */
>  	} iv;	/**< Initialisation vector parameters */
> +
> +	uint32_t block_size;
> +	/**< When RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS is
> reported, this is
> +	 * the block size of the algorithm, otherwise or when the value is 0,
> +	 * use the default block size provided in the capability.
> +	 * The value should be in the range defined by the bsf field in the
> +	 * cipher capability.
> +	 *
> +	 * - For AES-XTS it is the size of data-unit, from IEEE Std 1619-2007.
> +	 * For-each data-unit in the operation, the tweak(IV) value is
> +	 * assigned consecutively starting from the operation assigned
> tweak.
> +	 */
>  };
> 
>  /** Symmetric Authentication / Hash Algorithms diff --git
> a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index ae34f33..60ba839 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -96,6 +96,19 @@ struct rte_crypto_param_range {  };
> 
>  /**
> + * Crypto device supported block size flags for cipher algorithms
> + * Each flag represents single or range of supported block sizes  */
> +#define RTE_CRYPTO_CIPHER_BSF_ALL 0x1
> +/* All the sizes from the algorithm standard */ #define
> +RTE_CRYPTO_CIPHER_BSF_512_BYTES 0x2 #define
> +RTE_CRYPTO_CIPHER_BSF_520_BYTES 0x4 #define
> +RTE_CRYPTO_CIPHER_BSF_4048_BYTES 0x8 #define
> +RTE_CRYPTO_CIPHER_BSF_4096_BYTES 0x10 #define
> +RTE_CRYPTO_CIPHER_BSF_4160_BYTES 0x20 #define
> +RTE_CRYPTO_CIPHER_BSF_1M_BYTES 0x40
> +
> +/**
>   * Symmetric Crypto Capability
>   */
>  struct rte_cryptodev_symmetric_capability { @@ -122,11 +135,19 @@ struct
> rte_cryptodev_symmetric_capability {
>  			enum rte_crypto_cipher_algorithm algo;
>  			/**< cipher algorithm */
>  			uint16_t block_size;
> -			/**< algorithm block size */
> +			/**<
> +			 * algorithm block size
> +			 * For algorithms support more than single block size,
> +			 * this is the default block size supported by the
> +			 * driver, all the supported sizes are reflected in the
> +			 * bsf field.
> +			 */
>  			struct rte_crypto_param_range key_size;
>  			/**< cipher key size range */
>  			struct rte_crypto_param_range iv_size;
>  			/**< Initialisation vector data size range */
> +			uint32_t bsf;
> +			/**< Block size flags */
>  		} cipher;
>  		/**< Symmetric Cipher transform capabilities */
>  		struct {
> --
> 1.8.3.1


  parent reply	other threads:[~2021-02-26  5:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-04 14:34 [dpdk-dev] " Matan Azrad
2021-02-05 16:50 ` Zhang, Roy Fan
2021-02-08 12:10 ` Kusztal, ArkadiuszX
2021-02-08 13:36   ` Matan Azrad
2021-02-08 15:28     ` Kusztal, ArkadiuszX
2021-02-08 18:23       ` Matan Azrad
2021-02-26  7:50         ` Kusztal, ArkadiuszX
2021-02-26  5:01 ` Anoob Joseph [this message]
2021-03-01  7:55   ` [dpdk-dev] [EXT] " Matan Azrad
2021-03-01  9:29     ` Kusztal, ArkadiuszX
2021-03-14 12:18 ` [dpdk-dev] [PATCH] cryptodev: support multiple cipher data-units Matan Azrad
2021-04-04 15:17   ` [dpdk-dev] [PATCH v2] " Matan Azrad
     [not found]   ` <20210404150809.2154241-1-matan@nvidia.com>
2021-04-13 12:02     ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-13 16:39       ` Thomas Monjalon
2021-04-13 18:19 ` [dpdk-dev] [PATCH v3] " Thomas Monjalon
2021-04-13 19:48   ` Matan Azrad
2021-04-13 20:42 ` [dpdk-dev] [PATCH v4] " Thomas Monjalon
2021-04-14 18:37   ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-14 19:38     ` Thomas Monjalon
2021-04-14 19:43       ` Akhil Goyal
2021-04-14 20:17         ` Thomas Monjalon
2021-04-14 20:15 ` [dpdk-dev] [PATCH] doc: announce extension of crypto data-unit length Thomas Monjalon
2021-05-17 19:41   ` [dpdk-dev] [EXT] " Akhil Goyal
2021-07-31 17:10     ` Thomas Monjalon
2021-07-31 18:58   ` [dpdk-dev] " Ajit Khaparde
2021-08-02 11:10   ` Matan Azrad
2021-08-02 12:04   ` Thomas Monjalon
2021-04-14 20:21 ` [dpdk-dev] [PATCH v5] cryptodev: support multiple cipher data-units Thomas Monjalon
2021-04-15  8:35   ` [dpdk-dev] [EXT] " Akhil Goyal
2021-04-15 19:01     ` Akhil Goyal
2021-04-15 19:31       ` David Marchand

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=MWHPR18MB11682C7E16206EDF52F1AACBDF9D9@MWHPR18MB1168.namprd18.prod.outlook.com \
    --to=anoobj@marvell.com \
    --cc=adwivedi@marvell.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=asomalap@amd.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=g.singh@nxp.com \
    --cc=gakhil@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=jianjay.zhou@huawei.com \
    --cc=john.griffin@intel.com \
    --cc=matan@nvidia.com \
    --cc=michaelsh@marvell.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=rnagadheeraj@marvell.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=ruifeng.wang@arm.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).