[dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Matan Azrad]

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

Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Zhang, Roy Fan]

Hi Matan,

It is a good idea to be able to show the varied block sizes of each PMD/algo.

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Thursday, February 4, 2021 2:34 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Doherty, Declan <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>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Griffin, John <john.griffin@intel.com>; De Lara
> Guarch, Pablo <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: [PATCH] cryptodev: support multiple cipher block sizes

[SNIP] 

> +#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 */

The doubt I have is limited block sizes 32-bit bsf can represents. Although it is good enough now for AES-XTS but it already used 1/4 of all available representation of the different block sizes. If we are to include more block sizes for different algorithms we really don't have much room left.
Also bsf seems to be a duplication to existing block_size. 

There should be a better way to describe varied block sizes in capability.

>  		} cipher;
>  		/**< Symmetric Cipher transform capabilities */
>  		struct {
> --
> 1.8.3.1

Regards,
Fan

Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Kusztal, ArkadiuszX]

Hi Matan,

Few comments/questions inline with [Arek]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad
> Sent: Thursday, February 4, 2021 3:34 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Doherty, Declan <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>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Griffin, John <john.griffin@intel.com>; De Lara
> Guarch, Pablo <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: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes
> 
> 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.
[Arek] - Except that the last data block does not need to be n-bit long, beside that and lack of chaining it makes XTS no different to any other block cipher mode of operation.
Block size itself for XTS-AES is always 16 bytes in the first place which is AES constraint.
2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is data unit length that contains "data unit in bytes/ 16" AES blocks where last one can be incomplete.

> 
> 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.

[Arek] - Do you mean tweak increment per data unit? Like one op as a data stream (multiple data units) and tweak incremented by pmd?

> 
> 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.

[Arek] - nowadays algorithms rather don't have different block sizes, though I see people set this field even for stream ciphers.
If such algorithm would happen it probably could just get a suffix in crypto_cipher_enum. Otherwise some fixed size array could be added.

> +	 *
> +	 * - 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.
> +	 */
[Arek] - if data unit would be session value (key scope in xts naming) where the number of units would be taken from, sym_op->len ?
(For standard storage example: data unit size -> logical block size, sym_op->len -> range of consecutive logical blocks.)
If so it probably could be session-less op as this cipher key would be unusable after it.

>  };
> 
>  /** 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
[Arek] - when adding constants source should be attached as well.
> +
> +/**
>   * 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

Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Matan Azrad]

Hi Kuztal

From: Kusztal, ArkadiuszX
> Hi Matan,
> 
> Few comments/questions inline with [Arek]
> 
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad
> > Sent: Thursday, February 4, 2021 3:34 PM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; Doherty, Declan <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>; Zhang, Roy Fan
> > <roy.fan.zhang@intel.com>; Griffin, John <john.griffin@intel.com>; De
> > Lara Guarch, Pablo <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: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block
> > sizes
> >
> > 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.
> [Arek] - Except that the last data block does not need to be n-bit long, beside
> that and lack of chaining it makes XTS no different to any other block cipher
> mode of operation.
> Block size itself for XTS-AES is always 16 bytes in the first place which is AES
> constraint.
> 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is data unit
> length that contains "data unit in bytes/ 16" AES blocks where last one can be
> incomplete.
> 
> >
> > 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.
> 
> [Arek] - Do you mean tweak increment per data unit? Like one op as a data
> stream (multiple data units) and tweak incremented by pmd?

It can be defined differently per algorithm.
I know from AES-XTS standard that the tweak should be incremented by 1 per data-unit.
So, yes, here, the driver\device should take care for the incrementation.
  

> 
> >
> > 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.
> 
> [Arek] - nowadays algorithms rather don't have different block sizes, though I
> see people set this field even for stream ciphers.
> If such algorithm would happen it probably could just get a suffix in
> crypto_cipher_enum. Otherwise some fixed size array could be added.

First, if no different block size per algorithm, why do we need this parameter at all?

Second,
Cipher block defined to be like this D(E(b)) = b
D: decryption function
E: encryption function
P: plain-text block data.

In case of AES-XTS the cipher block size is the data-unit size.
There is a big range of optional data, see in standard.


> > +      *
> > +      * - 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.
> > +      */
> [Arek] - if data unit would be session value (key scope in xts naming) where the
> number of units would be taken from, sym_op->len ?

Yes, it is already defined there that it must be multiple of block size(data-unit in AES-XTS case).

> (For standard storage example: data unit size -> logical block size, sym_op->len
> -> range of consecutive logical blocks.) If so it probably could be session-less op
> as this cipher key would be unusable after it.
> 

Can be session and session-less modes.

If the user want to operate on different groups of blocks in the same stream
he can use the same session(key) with different ops.

Am I missing here?

> >  };
> >
> >  /** 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
> [Arek] - when adding constants source should be attached as well.
> > +
> > +/**
> >   * 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

Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Kusztal, ArkadiuszX]

> > > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block
> > > sizes
> > >
> > > 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.
> > [Arek] - Except that the last data block does not need to be n-bit
> > long, beside that and lack of chaining it makes XTS no different to
> > any other block cipher mode of operation.
> > Block size itself for XTS-AES is always 16 bytes in the first place
> > which is AES constraint.
> > 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is data
> > unit length that contains "data unit in bytes/ 16" AES blocks where
> > last one can be incomplete.
> >
> > >
> > > 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.
> >
> > [Arek] - Do you mean tweak increment per data unit? Like one op as a
> > data stream (multiple data units) and tweak incremented by pmd?
> 
> It can be defined differently per algorithm.
[Arek] - what do you mean?
> I know from AES-XTS standard that the tweak should be incremented by 1 per
> data-unit.
> So, yes, here, the driver\device should take care for the incrementation.
[Arek] - then it should be stated in rte_crypto_sym_op iv comments.

> 
> 
> >
> > >
> > > 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;
[Arek] - looking from your answers below, this one could just be aes_xts_dataunit_len.

> > > +     /**< 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.
> >
> > [Arek] - nowadays algorithms rather don't have different block sizes,
> > though I see people set this field even for stream ciphers.
> > If such algorithm would happen it probably could just get a suffix in
> > crypto_cipher_enum. Otherwise some fixed size array could be added.
> 
> First, if no different block size per algorithm, why do we need this parameter at
> all?
[Arek] - I am not sure but looks like informative, especially that it is only one 16bit long field.
 
> 
> Second,
> Cipher block defined to be like this D(E(b)) = b
> D: decryption function
> E: encryption function
> P: plain-text block data.
> 
> In case of AES-XTS the cipher block size is the data-unit size.
> There is a big range of optional data, see in standard.
[Arek] - Currently in DPDK we have 3 block cipher algorithms:
TDEA(3DES) - 8 byte block, AES - 16 byte block, KASUMI -8byte (but deprecated since 3G),
Additionally IPsec ietf defines NULL as block cipher with 1 byte len, but ETSI doesn't do that with EEA,EIA,NIA-0.

> 
> 
> > > +      *
> > > +      * - 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.
> > > +      */
> > [Arek] - if data unit would be session value (key scope in xts naming)
> > where the number of units would be taken from, sym_op->len ?
> 
> Yes, it is already defined there that it must be multiple of block size(data-unit in
> AES-XTS case).
[Arek]  - this comment was meant for cipher block modes that needs input aligned to block cipher len, like CBC padding.
In case of XTS it should be something like : multiple of xform xts_data_unit len or one of two:
- data unit len itself in case device does not support multiple data units.
- 0 and data unit len would be taken from session/xform in case device does not support multiple data units.

> 
> > (For standard storage example: data unit size -> logical block size,
> > sym_op->len
> > -> range of consecutive logical blocks.) If so it probably could be
> > -> session-less op
> > as this cipher key would be unusable after it.
> >
> 
> Can be session and session-less modes.
> 
> If the user want to operate on different groups of blocks in the same stream he
> can use the same session(key) with different ops.
[Arek] - yes, it should be possible to do that if user keep track of tweak value.

> 
> Am I missing here?
> 
> > >  };
> > >
> > >  /** 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
> > [Arek] - when adding constants source should be attached as well.
> > > +
> > > +/**
> > >   * 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

Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Matan Azrad]

Hi Kusztal

First, thank you for this review and the suggestions.

From: Kusztal, ArkadiuszX
> > > > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher
> > > > block sizes
> > > >
> > > > 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.
> > > [Arek] - Except that the last data block does not need to be n-bit
> > > long, beside that and lack of chaining it makes XTS no different to
> > > any other block cipher mode of operation.

The question is what is block:
The 16B of AES or the AES-XTS standard data-unit definition.

My intention here is like AES-XTS data-unit, and you understand it as AES 16B block(at least for this comment 😊).

Please try to understand it as data-unit (replace any "block" word in "data-unit")
Now, can you understand the commit log better without exceptions?

The important point for the API that I want, with you and the community help, to add is the "size" which the application and the drivers\devices must know in order to know how to decrypt an encrypted data.   

For AES-XTS this "size" is not always 16B.

So, if someone get a cipher-text which was encrypted by AES-XTS with initial tweak T and 2 keys K0,K1 it is not enough information in order to do decryption.
The 16B block of AES is not helping here.
Here, the user must know the data-unit size.
The formula D(E(b)) = b that I wrote below must use b as data-unit.
Are you agree?

> > > Block size itself for XTS-AES is always 16 bytes in the first place
> > > which is AES constraint.
> > > 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is
> > > data unit length that contains "data unit in bytes/ 16" AES blocks
> > > where last one can be incomplete.
> > > >
> > > > 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.
> > >
> > > [Arek] - Do you mean tweak increment per data unit? Like one op as a
> > > data stream (multiple data units) and tweak incremented by pmd?
> >
> > It can be defined differently per algorithm.
> [Arek] - what do you mean?

Maybe in other algorithms standards the IV can be changed differently than AES-XTS, I'm not familiar with all the algorithms 😊.

> > I know from AES-XTS standard that the tweak should be incremented by 1
> > per data-unit.
> > So, yes, here, the driver\device should take care for the incrementation.
> [Arek] - then it should be stated in rte_crypto_sym_op iv comments.

I stated it in the cipher transformation structure where the tweak is defined as IV for AES-XTS.

Do you think we need to add comment in the op too?

> >
> >
> > >
> > > >
> > > > 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;
> [Arek] - looking from your answers below, this one could just be
> aes_xts_dataunit_len.

Are you sure there is no any other cipher algorithm that have something similar to data-unit of AES-XTS?
 
> > > > +     /**< 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.
> > >
> > > [Arek] - nowadays algorithms rather don't have different block
> > > sizes, though I see people set this field even for stream ciphers.
> > > If such algorithm would happen it probably could just get a suffix
> > > in crypto_cipher_enum. Otherwise some fixed size array could be added.
> >
> > First, if no different block size per algorithm, why do we need this
> > parameter at all?
> [Arek] - I am not sure but looks like informative, especially that it is only one
> 16bit long field.

Yes, it is 16 bits, but it is not needed, I don't think applications use this capability if it is defined by definition per algorithm.
Looks like candidate for deprecation if so.

> >
> > Second,
> > Cipher block defined to be like this D(E(b)) = b
> > D: decryption function
> > E: encryption function
> > b: plain-text block data.
> >
> > In case of AES-XTS the cipher block size is the data-unit size.
> > There is a big range of optional data, see in standard.
> [Arek] - Currently in DPDK we have 3 block cipher algorithms:
> TDEA(3DES) - 8 byte block, AES - 16 byte block, KASUMI -8byte (but deprecated
> since 3G), Additionally IPsec ietf defines NULL as block cipher with 1 byte len,
> but ETSI doesn't do that with EEA,EIA,NIA-0.

OK

> >
> >
> > > > +      *
> > > > +      * - 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.
> > > > +      */
> > > [Arek] - if data unit would be session value (key scope in xts
> > > naming) where the number of units would be taken from, sym_op->len ?
> >
> > Yes, it is already defined there that it must be multiple of block
> > size(data-unit in AES-XTS case).
> [Arek]  - this comment was meant for cipher block modes that needs input
> aligned to block cipher len, like CBC padding.

So, Do you think the current comment is wrong?

> In case of XTS it should be something like : multiple of xform xts_data_unit len
> or one of two:
> - data unit len itself in case device does not support multiple data units.
> - 0 and data unit len would be taken from session/xform in case device does not
> support multiple data units.

Yes, the first one doesn't break API, so it is better.

> >
> > > (For standard storage example: data unit size -> logical block size,
> > > sym_op->len
> > > -> range of consecutive logical blocks.) If so it probably could be
> > > -> session-less op
> > > as this cipher key would be unusable after it.
> > >
> >
> > Can be session and session-less modes.
> >
> > If the user want to operate on different groups of blocks in the same
> > stream he can use the same session(key) with different ops.
> [Arek] - yes, it should be possible to do that if user keep track of tweak value.
> 
> >
> > Am I missing here?
> >
> > > >  };
> > > >
> > > >  /** 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
> > > [Arek] - when adding constants source should be attached as well.
> > > > +
> > > > +/**
> > > >   * 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

Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher block sizes

[Anoob Joseph]

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

Re: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Monday, February 8, 2021 7:23 PM
> To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Doherty, Declan <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>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Griffin, John <john.griffin@intel.com>; De Lara
> Guarch, Pablo <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: RE: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes
> 
> Hi Kusztal
> 
> First, thank you for this review and the suggestions.
> 
> From: Kusztal, ArkadiuszX
> > > > > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher
> > > > > block sizes
> > > > >
> > > > > 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.
> > > > [Arek] - Except that the last data block does not need to be n-bit
> > > > long, beside that and lack of chaining it makes XTS no different
> > > > to any other block cipher mode of operation.
> 
> The question is what is block:
> The 16B of AES or the AES-XTS standard data-unit definition.
> 
> My intention here is like AES-XTS data-unit, and you understand it as AES 16B
> block(at least for this comment 😊).
[Arek] - yes, and right now you are correct. Data unit of data stream, not algorithm block size.
> 
> Please try to understand it as data-unit (replace any "block" word in "data-unit")
> Now, can you understand the commit log better without exceptions?
> 
> The important point for the API that I want, with you and the community help,
> to add is the "size" which the application and the drivers\devices must know in
> order to know how to decrypt an encrypted data.
> 
> For AES-XTS this "size" is not always 16B.
> 
> So, if someone get a cipher-text which was encrypted by AES-XTS with initial
> tweak T and 2 keys K0,K1 it is not enough information in order to do decryption.
> The 16B block of AES is not helping here.
> Here, the user must know the data-unit size.
> The formula D(E(b)) = b that I wrote below must use b as data-unit.
> Are you agree?
> 
> > > > Block size itself for XTS-AES is always 16 bytes in the first
> > > > place which is AES constraint.
> > > > 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is
> > > > data unit length that contains "data unit in bytes/ 16" AES blocks
> > > > where last one can be incomplete.
> > > > >
> > > > > 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.
> > > >
> > > > [Arek] - Do you mean tweak increment per data unit? Like one op as
> > > > a data stream (multiple data units) and tweak incremented by pmd?
> > >
> > > It can be defined differently per algorithm.
> > [Arek] - what do you mean?
> 
> Maybe in other algorithms standards the IV can be changed differently than AES-
> XTS, I'm not familiar with all the algorithms 😊.
> 
> > > I know from AES-XTS standard that the tweak should be incremented by
> > > 1 per data-unit.
> > > So, yes, here, the driver\device should take care for the incrementation.
> > [Arek] - then it should be stated in rte_crypto_sym_op iv comments.
> 
> I stated it in the cipher transformation structure where the tweak is defined as IV
> for AES-XTS.
> 
> Do you think we need to add comment in the op too?
[Arek] - on the other hand no, having it in xform should be ok, especially that no really good place to put it in op
> 
> > >
> > >
> > > >
> > > > >
> > > > > 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;
> > [Arek] - looking from your answers below, this one could just be
> > aes_xts_dataunit_len.
> 
> Are you sure there is no any other cipher algorithm that have something similar
> to data-unit of AES-XTS?
[Arek] - from what we currently have - no by definition but I agree, it actually could be something like dataunit_len;
> 
> > > > > +     /**< 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.
> > > >
> > > > [Arek] - nowadays algorithms rather don't have different block
> > > > sizes, though I see people set this field even for stream ciphers.
> > > > If such algorithm would happen it probably could just get a suffix
> > > > in crypto_cipher_enum. Otherwise some fixed size array could be added.
> > >
> > > First, if no different block size per algorithm, why do we need this
> > > parameter at all?
> > [Arek] - I am not sure but looks like informative, especially that it
> > is only one 16bit long field.
> 
> Yes, it is 16 bits, but it is not needed, I don't think applications use this capability
> if it is defined by definition per algorithm.
> Looks like candidate for deprecation if so.
[Arek] - this actually should be for another discussion, as for varying block size RC5 can have different block sizes (but you will rather not find it in modern cipher suites).
Another option is wide block encryption though I am not sure what is current popularity of it.
From the network perspective current trend is to go for stream ciphers (GCM, CCM, ChaCha) and stream cipher is obvious choice for wireless.

> 
> > >
> > > Second,
> > > Cipher block defined to be like this D(E(b)) = b
> > > D: decryption function
> > > E: encryption function
> > > b: plain-text block data.
> > >
> > > In case of AES-XTS the cipher block size is the data-unit size.
> > > There is a big range of optional data, see in standard.
> > [Arek] - Currently in DPDK we have 3 block cipher algorithms:
> > TDEA(3DES) - 8 byte block, AES - 16 byte block, KASUMI -8byte (but
> > deprecated since 3G), Additionally IPsec ietf defines NULL as block
> > cipher with 1 byte len, but ETSI doesn't do that with EEA,EIA,NIA-0.
> 
> OK
> 
> > >
> > >
> > > > > +      *
> > > > > +      * - 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.
> > > > > +      */
> > > > [Arek] - if data unit would be session value (key scope in xts
> > > > naming) where the number of units would be taken from, sym_op->len ?
> > >
> > > Yes, it is already defined there that it must be multiple of block
> > > size(data-unit in AES-XTS case).
> > [Arek]  - this comment was meant for cipher block modes that needs
> > input aligned to block cipher len, like CBC padding.
> 
> So, Do you think the current comment is wrong?
Arek] - yes, current comment is wrong. It does not allow XTS data unit that is not multiple of block size.
 
> 
> > In case of XTS it should be something like : multiple of xform
> > xts_data_unit len or one of two:
> > - data unit len itself in case device does not support multiple data units.
> > - 0 and data unit len would be taken from session/xform in case device
> > does not support multiple data units.
> 
> Yes, the first one doesn't break API, so it is better.
[Arek] - ok so something like:
Multiple of xform xts_data_unit or data unit len itself in case device does not support multiple data units.

Maybe some additional option would be needed if PMD can work both ways (with and without auto tweak increment).

> 
> > >
> > > > (For standard storage example: data unit size -> logical block
> > > > size, sym_op->len
> > > > -> range of consecutive logical blocks.) If so it probably could
> > > > -> be session-less op
> > > > as this cipher key would be unusable after it.
> > > >
> > >
> > > Can be session and session-less modes.
> > >
> > > If the user want to operate on different groups of blocks in the
> > > same stream he can use the same session(key) with different ops.
> > [Arek] - yes, it should be possible to do that if user keep track of tweak value.
> >
> > >
> > > Am I missing here?
> > >
> > > > >  };
> > > > >
> > > > >  /** 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
> > > > [Arek] - when adding constants source should be attached as well.
> > > > > +
> > > > > +/**
> > > > >   * 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

Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher block sizes

[Matan Azrad]

From: Anoob Joseph
> 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?

Yes, we want to define well what is the "data-unit" size from AES-XTS standard per session (or operation), then, to allow to the PMD users to send multiple data-units in one operation.
The initial tweak(for the first data-unit) will be set by the user in the operation, and according the standard(probably what you call "spec") the rest data-units tweak values should  be assigned consecutively, so this part will be done by the PMD\device in multiple data-units case. 

> 
> 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?

Sure, this is the offload, no? to support what the algorithm defines.

> 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).

Sure,
For any amount of consecutive data-units, the user can do encrypt\decrypt in one operation: 1, 2, all the disk..... in one mbuf or chain of mbufs...
But the blob of data must be multiple of the session data-unit size parameter that I want to define now in the session API(\ transformation).

> 3. On top level, this requirement has similarities to rte_security. Did you
> consider that route?

No, but why do you care? The regular crypto API should support it too, it is basic...


> Thanks,
> Anoob

Thank you.
 
> > -----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

Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher block sizes

[Kusztal, ArkadiuszX]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Matan Azrad
> Sent: Monday, March 1, 2021 8:56 AM
> To: Anoob Joseph <anoobj@marvell.com>; dev@dpdk.org
> Cc: Doherty, Declan <declan.doherty@intel.com>; Somalapuram Amaranath
> <asomalap@amd.com>; Ruifeng Wang <ruifeng.wang@arm.com>; Ajit
> Khaparde <ajit.khaparde@broadcom.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; Griffin, John <john.griffin@intel.com>; De Lara
> Guarch, Pablo <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
> 
> 
> 
> From: Anoob Joseph
> > 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?
> 
> Yes, we want to define well what is the "data-unit" size from AES-XTS standard
> per session (or operation), then, to allow to the PMD users to send multiple
> data-units in one operation.
> The initial tweak(for the first data-unit) will be set by the user in the operation,
> and according the standard(probably what you call "spec") the rest data-units
> tweak values should  be assigned consecutively, so this part will be done by the
> PMD\device in multiple data-units case.
> 
> >
> > 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?
>
[Arek] - data units (including final) are of the same size, ciphertext stealing may concern only last AES block from every data unit if data unit size is not multiple of AES block size.
As there is ciphertext stealing no padding needed.
 
> Sure, this is the offload, no? to support what the algorithm defines.
.
> 
> > 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).
> 
> Sure,
> For any amount of consecutive data-units, the user can do encrypt\decrypt in
> one operation: 1, 2, all the disk..... in one mbuf or chain of mbufs...
> But the blob of data must be multiple of the session data-unit size parameter
> that I want to define now in the session API(\ transformation).
> 
> > 3. On top level, this requirement has similarities to rte_security.
> > Did you consider that route?
> 
> No, but why do you care? The regular crypto API should support it too, it is
> basic...
> 
> 
> > Thanks,
> > Anoob
> 
> Thank you.
> 
> > > -----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

[dpdk-dev] [PATCH] cryptodev: support multiple cipher data-units

[Matan Azrad]

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.

For AES standard the block size is 16 bytes.
For AES in XTS mode, the data to be encrypted\decrypted does not have to
be multiple of 16B size, the unit of data is called data-unit.
The data-unit size can be any size in range [16B, 2^24B], so, in this
case, a data stream is divided into N amount of equal data-units and
must be encrypted\decrypted in the same data-unit resolution.

The current cryptodev API doesn't allow the user to select a specific
data-unit length supported by the devices.
In addition, there is no definition how the IV is detected per data-unit
when single operation includes more than one data-unit.

That causes applications to use single operation per data-unit even though
all the data is continuous in memory what reduces datapath performance.

Add a new feature flag to support multiple data-unit sizes, called
RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS.
Add a new field in cipher capability, called dataunit_set,
where the devices can report the range of the supported data-unit sizes.
Add a new cipher transformation field, called dataunit_len, where the user
can select the data-unit length for all the operations.

All the new fields do not change the size of their structures.

Using a bitmap to report the supported data-unit 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
among different devices.

Signed-off-by: Matan Azrad <matan@nvidia.com>
---
 
First patch on it was sent as RFC.
This is first formal version, I updated according to comments on RFC discussions:
- Use data-unit term instead of block.
- Update cipher length description in OP.
- Improve descriptions on xform and capability.
- Improve commit log.

You welcome to comment more.
Please pay attention that a new fields was added in non-experimental structures but thier sizes hasn't changed.


 doc/guides/cryptodevs/features/default.ini |  1 +
 doc/guides/cryptodevs/overview.rst         |  3 +++
 doc/guides/rel_notes/release_21_05.rst     |  6 ++++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 17 +++++++++++++++--
 lib/librte_cryptodev/rte_cryptodev.c       |  2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 18 ++++++++++++++++++
 6 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 17b177f..978bb30 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -31,6 +31,7 @@ CPU crypto             =
 Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
+Cipher multiple data units =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e2a1e08..0597d25 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -46,6 +46,9 @@ Supported Feature Flags
    - "Digest encrypted" feature flag means PMD support hash-cipher cases,
      where generated digest is appended to and encrypted with the data.
 
+   - "CIPHER_MULITPLE_DATA_UNITS" feature flag means PMD support operations
+      on multiple data-units message.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 88e7607..e4e41df 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -91,6 +91,12 @@ New Features
   * Added a command line option to configure forced speed for Ethernet port.
     ``dpdk-testpmd -c 0xff  -- -i  --eth-link-speed N``
 
+* **Added feature to support multiple data-units on cryptodev library API.**
+
+  The Cryptodev library has been enhanced to allow operations on multiple
+  data-units for AES-XTS algorithm, the data-unit length should be set in the
+  transformation. A capability for it was added too.
+
 
 Removed Items
 -------------
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d572ec..6a07666 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 dataunit_len;
+	/**< When RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS is enabled,
+	 * this is the data-unit length of the algorithm, otherwise or when the
+	 * value is 0, use the operation length.
+	 * The value should be in the range defined by the dataunit_set 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 IV.
+	 */
 };
 
 /** Symmetric Authentication / Hash Algorithms
@@ -701,9 +713,10 @@ struct rte_crypto_sym_op {
 					 /**< The message length, in bytes, of the
 					  * source buffer on which the cryptographic
 					  * operation will be computed.
+					  * This is also the same as the result length.
 					  * This must be a multiple of the block size
-					  * if a block cipher is being used. This is
-					  * also the same as the result length.
+					  * or a multiple of data-unit length as
+					  * described in xform.
 					  *
 					  * @note
 					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 40f55a3..51f8448 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -617,6 +617,8 @@ struct rte_cryptodev_sym_session_pool_private_data {
 		return "SYM_SESSIONLESS";
 	case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
 		return "NON_BYTE_ALIGNED_DATA";
+	case RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS:
+		return "CIPHER_MULITPLE_DATA_UNITS";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index ae34f33..cd914ff 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -96,6 +96,17 @@ struct rte_crypto_param_range {
 };
 
 /**
+ * Data-unit lengths of cipher algorithms, each bit represents single or
+ * range of data-unit lengths
+ */
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES	(1 << 0)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_520_BYTES	(1 << 1)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4048_BYTES	(1 << 2)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES	(1 << 3)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4160_BYTES	(1 << 4)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_1M_BYTES	(1 << 5)
+
+/**
  * Symmetric Crypto Capability
  */
 struct rte_cryptodev_symmetric_capability {
@@ -127,6 +138,11 @@ struct rte_cryptodev_symmetric_capability {
 			/**< cipher key size range */
 			struct rte_crypto_param_range iv_size;
 			/**< Initialisation vector data size range */
+			uint32_t dataunit_set;
+			/**<
+			 * A bitmap for a set of the supported data-unit lengths
+			 * 0 for any defined length in the algorithm standard
+			 */
 		} cipher;
 		/**< Symmetric Cipher transform capabilities */
 		struct {
@@ -461,6 +477,8 @@ struct rte_cryptodev_asym_capability_idx {
 /**< Support operations on data which is not byte aligned */
 #define RTE_CRYPTODEV_FF_SYM_RAW_DP			(1ULL << 24)
 /**< Support accelerator specific symmetric raw data-path APIs */
+#define RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS	(1ULL << 25)
+/**< Support operations on multiple data-units data */
 
 /**
  * Get the name of a crypto device feature flag
-- 
1.8.3.1

[dpdk-dev] [PATCH v2] cryptodev: support multiple cipher data-units

[Matan Azrad]

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.

For AES standard the block size is 16 bytes.
For AES in XTS mode, the data to be encrypted\decrypted does not have to
be multiple of 16B size, the unit of data is called data-unit.
The data-unit size can be any size in range [16B, 2^24B], so, in this
case, a data stream is divided into N amount of equal data-units and
must be encrypted\decrypted in the same data-unit resolution.

The current cryptodev API doesn't allow the user to select a specific
data-unit length supported by the devices.
In addition, there is no definition how the IV is detected per data-unit
when single operation includes more than one data-unit.

That causes applications to use single operation per data-unit even though
all the data is continuous in memory what reduces datapath performance.

Add a new feature flag to support multiple data-unit sizes, called
RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS.
Add a new field in cipher capability, called dataunit_set,
where the devices can report the range of the supported data-unit sizes.
Add a new cipher transformation field, called dataunit_len, where the user
can select the data-unit length for all the operations.

All the new fields do not change the size of their structures.

Using a bitmap to report the supported data-unit 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
among different devices.

Signed-off-by: Matan Azrad <matan@nvidia.com>
---
RFC->V1:
- Use data-unit term instead of block.
- Update cipher length description in OP.
- Improve descriptions on xform and capability.
- Improve commit log.

V1->V2:
- Fix typo: MULITPLE->MULITPLE.
- Remain only planned supported sizes for data-unit capability.



 doc/guides/cryptodevs/features/default.ini |  1 +
 doc/guides/cryptodevs/overview.rst         |  3 +++
 doc/guides/rel_notes/release_21_05.rst     |  6 ++++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 17 +++++++++++++++--
 lib/librte_cryptodev/rte_cryptodev.c       |  2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 15 +++++++++++++++
 6 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 17b177fc45..978bb30cc1 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -31,6 +31,7 @@ CPU crypto             =
 Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
+Cipher multiple data units =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e2a1e08ec1..e24e3e1993 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -46,6 +46,9 @@ Supported Feature Flags
    - "Digest encrypted" feature flag means PMD support hash-cipher cases,
      where generated digest is appended to and encrypted with the data.
 
+   - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
+      on multiple data-units message.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 873140b433..1537fac4bc 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -126,6 +126,12 @@ New Features
   * Added command to display Rx queue used descriptor count.
     ``show port (port_id) rxq (queue_id) desc used count``
 
+* **Added feature to support multiple data-units on cryptodev library API.**
+
+  The Cryptodev library has been enhanced to allow operations on multiple
+  data-units for AES-XTS algorithm, the data-unit length should be set in the
+  transformation. A capability for it was added too.
+
 
 Removed Items
 -------------
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d572ec057..5973e31f30 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 dataunit_len;
+	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is enabled,
+	 * this is the data-unit length of the algorithm, otherwise or when the
+	 * value is 0, use the operation length.
+	 * The value should be in the range defined by the dataunit_set 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 IV.
+	 */
 };
 
 /** Symmetric Authentication / Hash Algorithms
@@ -701,9 +713,10 @@ struct rte_crypto_sym_op {
 					 /**< The message length, in bytes, of the
 					  * source buffer on which the cryptographic
 					  * operation will be computed.
+					  * This is also the same as the result length.
 					  * This must be a multiple of the block size
-					  * if a block cipher is being used. This is
-					  * also the same as the result length.
+					  * or a multiple of data-unit length as
+					  * described in xform.
 					  *
 					  * @note
 					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 40f55a3cd0..e02e001325 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -617,6 +617,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
 		return "SYM_SESSIONLESS";
 	case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
 		return "NON_BYTE_ALIGNED_DATA";
+	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
+		return "CIPHER_MULTIPLE_DATA_UNITS";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index ae34f33f69..c274e208ed 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -95,6 +95,14 @@ struct rte_crypto_param_range {
 	 */
 };
 
+/**
+ * Data-unit lengths of cipher algorithms, each bit represents single or
+ * range of data-unit lengths
+ */
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES	(1 << 0)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES	(1 << 1)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_1M_BYTES	(1 << 2)
+
 /**
  * Symmetric Crypto Capability
  */
@@ -127,6 +135,11 @@ struct rte_cryptodev_symmetric_capability {
 			/**< cipher key size range */
 			struct rte_crypto_param_range iv_size;
 			/**< Initialisation vector data size range */
+			uint32_t dataunit_set;
+			/**<
+			 * A bitmap for a set of the supported data-unit lengths
+			 * 0 for any defined length in the algorithm standard
+			 */
 		} cipher;
 		/**< Symmetric Cipher transform capabilities */
 		struct {
@@ -461,6 +474,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support operations on data which is not byte aligned */
 #define RTE_CRYPTODEV_FF_SYM_RAW_DP			(1ULL << 24)
 /**< Support accelerator specific symmetric raw data-path APIs */
+#define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
+/**< Support operations on multiple data-units message */
 
 /**
  * Get the name of a crypto device feature flag
-- 
2.25.1

Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: support multiple cipher data-units

[Akhil Goyal]

Hi Matan,

> 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.
> 
> For AES standard the block size is 16 bytes.
> For AES in XTS mode, the data to be encrypted\decrypted does not have to
> be multiple of 16B size, the unit of data is called data-unit.
> The data-unit size can be any size in range [16B, 2^24B], so, in this
> case, a data stream is divided into N amount of equal data-units and
> must be encrypted\decrypted in the same data-unit resolution.
> 
> The current cryptodev API doesn't allow the user to select a specific
> data-unit length supported by the devices.
> In addition, there is no definition how the IV is detected per data-unit
> when single operation includes more than one data-unit.
> 
> That causes applications to use single operation per data-unit even though
> all the data is continuous in memory what reduces datapath performance.
> 
> Add a new feature flag to support multiple data-unit sizes, called
> RTE_CRYPTODEV_FF_CIPHER_MULITPLE_DATA_UNITS.
> Add a new field in cipher capability, called dataunit_set,
> where the devices can report the range of the supported data-unit sizes.
> Add a new cipher transformation field, called dataunit_len, where the user
> can select the data-unit length for all the operations.
> 
> All the new fields do not change the size of their structures.
> 
Please check that the CI is failing. I see that ignore exception is present in 
devtools/libabigail.abignore For rte_cryptodev. But not sure why this is still
failing. Can you check?

Regards,
Akhil

> Using a bitmap to report the supported data-unit 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
> among different devices.
> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---

Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: support multiple cipher data-units

[Thomas Monjalon]

13/04/2021 14:02, Akhil Goyal:
> > All the new fields do not change the size of their structures.
> 
> Please check that the CI is failing. I see that ignore exception is present in 
> devtools/libabigail.abignore For rte_cryptodev. But not sure why this is still
> failing. Can you check?

There are 2 new fields:
	- rte_cryptodev_symmetric_capability.cipher.dataunit_set
	- rte_crypto_cipher_xform.dataunit_len

This is how the struct sizes are affected (before / after):

       struct       \      arch    |  32-bit |  64-bit |
-----------------------------------|---------|---------|
rte_cryptodev_symmetric_capability | 36 / 36 | 36 / 36 |
rte_crypto_cipher_xform            | 20 / 24 | 32 / 32 |

There is no change in rte_cryptodev_symmetric_capability because
the field is added in a light branch of the union.

The 64-bit size of rte_crypto_cipher_xform is unchanged (32)
because there were 4 padding bytes at the end (28 + 4).
But the 32-bit version has not such padding at the end,
so there is a breakage.

The only hole in 32-bit rte_crypto_cipher_xform is
2 bytes between key and iv.
Can we define dataunit_len as uint16_t?

The other side to check when playing with the ABI
is the default value of the holes for the new field.
The driver must work properly in case the application
did not explicitly set the new fields.
In general it means the compatible API should have memset(0).
In this case, it seems the new fields will be used only
in a new mlx5 driver, so it should be OK for now.
But usage of the new fields in an existing driver must
be checked carefully during the compatibility period.

[dpdk-dev] [PATCH v3] cryptodev: support multiple cipher data-units

[Thomas Monjalon]

From: Matan Azrad <matan@nvidia.com>

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.

For AES standard the block size is 16 bytes.
For AES in XTS mode, the data to be encrypted\decrypted does not have to
be multiple of 16B size, the unit of data is called data-unit.
The data-unit size can be any size in range [16B, 2^24B], so, in this
case, a data stream is divided into N amount of equal data-units and
must be encrypted\decrypted in the same data-unit resolution.

For ABI compatibility reason, the size is limited to 64K (16-bit field).
The new field dataunit_len is inserted in a struct padding hole,
which is only 2 bytes long in 32-bit build.
It could be extended later during an ABI-breakage window.

The current cryptodev API doesn't allow the user to select a specific
data-unit length supported by the devices.
In addition, there is no definition how the IV is detected per data-unit
when single operation includes more than one data-unit.

That causes applications to use single operation per data-unit even though
all the data is continuous in memory what reduces datapath performance.

Add a new feature flag to support multiple data-unit sizes, called
RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS.
Add a new field in cipher capability, called dataunit_set,
where the devices can report the range of the supported data-unit sizes.
Add a new cipher transformation field, called dataunit_len, where the user
can select the data-unit length for all the operations.

All the new fields do not change the size of their structures,
by filling some struct padding holes.
They are added as exceptions in the ABI check file libabigail.abignore.

Using a bitmap to report the supported data-unit 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
among different devices.

Signed-off-by: Matan Azrad <matan@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v1:
- Use data-unit term instead of block.
- Update cipher length description in OP.
- Improve descriptions on xform and capability.
- Improve commit log.

v2:
- Fix typo: MULITPLE->MULTIPLE.
- Remain only planned supported sizes for data-unit capability.

v3:
- Improve some comments.
- Fix ABI breakage.

Note: the suppression rules work in libabigail for this patch,
but not sure it is really considering the offsets defined in the file.

---
 devtools/libabigail.abignore               | 12 +++++++++++-
 doc/guides/cryptodevs/features/default.ini |  1 +
 doc/guides/cryptodevs/overview.rst         |  3 +++
 doc/guides/rel_notes/release_21_05.rst     |  6 ++++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 18 ++++++++++++++++--
 lib/librte_cryptodev/rte_cryptodev.c       |  2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 16 ++++++++++++++++
 7 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 6c0b38984e..bce940f2df 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -19,4 +19,14 @@
 ; Ignore fields inserted in cacheline boundary of rte_cryptodev
 [suppress_type]
         name = rte_cryptodev
-        has_data_member_inserted_between = {offset_after(attached), end}
\ No newline at end of file
+        has_data_member_inserted_between = {offset_after(attached), end}
+
+; Ignore fields inserted in union boundary of rte_cryptodev_symmetric_capability
+[suppress_type]
+        name = rte_cryptodev_symmetric_capability
+        has_data_member_inserted_between = {offset_after(cipher.iv_size), end}
+
+; Ignore fields inserted in middle padding of rte_crypto_cipher_xform
+[suppress_type]
+        name = rte_crypto_cipher_xform
+        has_data_member_inserted_between = {offset_after(key), offset_of(iv)}
diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 17b177fc45..978bb30cc1 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -31,6 +31,7 @@ CPU crypto             =
 Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
+Cipher multiple data units =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e2a1e08ec1..e24e3e1993 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -46,6 +46,9 @@ Supported Feature Flags
    - "Digest encrypted" feature flag means PMD support hash-cipher cases,
      where generated digest is appended to and encrypted with the data.
 
+   - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
+      on multiple data-units message.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 9a666b629d..2dc776c35e 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -145,6 +145,12 @@ New Features
 
   * Added support for preferred busy polling.
 
+* **Added support of multiple data-units in cryptodev API.**
+
+  The cryptodev library has been enhanced to allow operations on multiple
+  data-units for AES-XTS algorithm, the data-unit length should be set in the
+  transformation. A capability for it was added too.
+
 * **Updated Mellanox RegEx PMD.**
 
   * Added support for multi-segments mbuf.
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d572ec057..ec45714fc3 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -222,6 +222,19 @@ struct rte_crypto_cipher_xform {
 	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
 	 *  - Both keys must have the same size.
 	 **/
+
+	uint16_t dataunit_len;
+	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is enabled,
+	 * this is the data-unit length of the algorithm,
+	 * otherwise or when the value is 0, use the operation length.
+	 * The value should be in the range defined by the dataunit_set 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 IV.
+	 */
+
 	struct {
 		uint16_t offset;
 		/**< Starting point for Initialisation Vector or Counter,
@@ -701,9 +714,10 @@ struct rte_crypto_sym_op {
 					 /**< The message length, in bytes, of the
 					  * source buffer on which the cryptographic
 					  * operation will be computed.
+					  * This is also the same as the result length.
 					  * This must be a multiple of the block size
-					  * if a block cipher is being used. This is
-					  * also the same as the result length.
+					  * or a multiple of data-unit length
+					  * as described in xform.
 					  *
 					  * @note
 					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 40f55a3cd0..e02e001325 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -617,6 +617,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
 		return "SYM_SESSIONLESS";
 	case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
 		return "NON_BYTE_ALIGNED_DATA";
+	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
+		return "CIPHER_MULTIPLE_DATA_UNITS";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index ae34f33f69..f6972a7d19 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -95,6 +95,15 @@ struct rte_crypto_param_range {
 	 */
 };
 
+/**
+ * Data-unit supported lengths of cipher algorithms.
+ * A bit can represent any set of data-unit sizes
+ * (single size, multiple size, range, etc).
+ */
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES	(1 << 0)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES	(1 << 1)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_1M_BYTES	(1 << 2)
+
 /**
  * Symmetric Crypto Capability
  */
@@ -127,6 +136,11 @@ struct rte_cryptodev_symmetric_capability {
 			/**< cipher key size range */
 			struct rte_crypto_param_range iv_size;
 			/**< Initialisation vector data size range */
+			uint32_t dataunit_set;
+			/**<
+			 * A bitmap for a set of the supported data-unit lengths.
+			 * 0 for any length defined in the algorithm standard.
+			 */
 		} cipher;
 		/**< Symmetric Cipher transform capabilities */
 		struct {
@@ -461,6 +475,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support operations on data which is not byte aligned */
 #define RTE_CRYPTODEV_FF_SYM_RAW_DP			(1ULL << 24)
 /**< Support accelerator specific symmetric raw data-path APIs */
+#define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
+/**< Support operations on multiple data-units message */
 
 /**
  * Get the name of a crypto device feature flag
-- 
2.31.1

Re: [dpdk-dev] [PATCH v3] cryptodev: support multiple cipher data-units

[Matan Azrad]

Hi

Small comment

From: Thomas Monjalon
> From: Matan Azrad <matan@nvidia.com>
> 
> 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.
> 
> For AES standard the block size is 16 bytes.
> For AES in XTS mode, the data to be encrypted\decrypted does not have to be
> multiple of 16B size, the unit of data is called data-unit.
> The data-unit size can be any size in range [16B, 2^24B], so, in this case, a data
> stream is divided into N amount of equal data-units and must be
> encrypted\decrypted in the same data-unit resolution.
> 
> For ABI compatibility reason, the size is limited to 64K (16-bit field).
> The new field dataunit_len is inserted in a struct padding hole, which is only 2
> bytes long in 32-bit build.
> It could be extended later during an ABI-breakage window.
> 
> The current cryptodev API doesn't allow the user to select a specific data-unit
> length supported by the devices.
> In addition, there is no definition how the IV is detected per data-unit when
> single operation includes more than one data-unit.
> 
> That causes applications to use single operation per data-unit even though all
> the data is continuous in memory what reduces datapath performance.
> 
> Add a new feature flag to support multiple data-unit sizes, called
> RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS.
> Add a new field in cipher capability, called dataunit_set, where the devices can
> report the range of the supported data-unit sizes.
> Add a new cipher transformation field, called dataunit_len, where the user can
> select the data-unit length for all the operations.
> 
> All the new fields do not change the size of their structures, by filling some
> struct padding holes.
> They are added as exceptions in the ABI check file libabigail.abignore.
> 
> Using a bitmap to report the supported data-unit 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 among different
> devices.
> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v1:
> - Use data-unit term instead of block.
> - Update cipher length description in OP.
> - Improve descriptions on xform and capability.
> - Improve commit log.
> 
> v2:
> - Fix typo: MULITPLE->MULTIPLE.
> - Remain only planned supported sizes for data-unit capability.
> 
> v3:
> - Improve some comments.
> - Fix ABI breakage.
> 
> Note: the suppression rules work in libabigail for this patch, but not sure it is
> really considering the offsets defined in the file.
> 
> ---
>  devtools/libabigail.abignore               | 12 +++++++++++-
>  doc/guides/cryptodevs/features/default.ini |  1 +
>  doc/guides/cryptodevs/overview.rst         |  3 +++
>  doc/guides/rel_notes/release_21_05.rst     |  6 ++++++
>  lib/librte_cryptodev/rte_crypto_sym.h      | 18 ++++++++++++++++--
>  lib/librte_cryptodev/rte_cryptodev.c       |  2 ++
>  lib/librte_cryptodev/rte_cryptodev.h       | 16 ++++++++++++++++
>  7 files changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore index
> 6c0b38984e..bce940f2df 100644
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -19,4 +19,14 @@
>  ; Ignore fields inserted in cacheline boundary of rte_cryptodev  [suppress_type]
>          name = rte_cryptodev
> -        has_data_member_inserted_between = {offset_after(attached), end}
> \ No newline at end of file
> +        has_data_member_inserted_between = {offset_after(attached),
> + end}
> +
> +; Ignore fields inserted in union boundary of
> +rte_cryptodev_symmetric_capability
> +[suppress_type]
> +        name = rte_cryptodev_symmetric_capability
> +        has_data_member_inserted_between =
> +{offset_after(cipher.iv_size), end}
> +
> +; Ignore fields inserted in middle padding of rte_crypto_cipher_xform
> +[suppress_type]
> +        name = rte_crypto_cipher_xform
> +        has_data_member_inserted_between = {offset_after(key),
> +offset_of(iv)}
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 17b177fc45..978bb30cc1 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -31,6 +31,7 @@ CPU crypto             =
>  Symmetric sessionless  =
>  Non-Byte aligned data  =
>  Sym raw data path API  =
> +Cipher multiple data units =
> 
>  ;
>  ; Supported crypto algorithms of a default crypto driver.
> diff --git a/doc/guides/cryptodevs/overview.rst
> b/doc/guides/cryptodevs/overview.rst
> index e2a1e08ec1..e24e3e1993 100644
> --- a/doc/guides/cryptodevs/overview.rst
> +++ b/doc/guides/cryptodevs/overview.rst
> @@ -46,6 +46,9 @@ Supported Feature Flags
>     - "Digest encrypted" feature flag means PMD support hash-cipher cases,
>       where generated digest is appended to and encrypted with the data.
> 
> +   - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support
> operations
> +      on multiple data-units message.
> +
> 
>  Supported Cipher Algorithms
>  ---------------------------
> diff --git a/doc/guides/rel_notes/release_21_05.rst
> b/doc/guides/rel_notes/release_21_05.rst
> index 9a666b629d..2dc776c35e 100644
> --- a/doc/guides/rel_notes/release_21_05.rst
> +++ b/doc/guides/rel_notes/release_21_05.rst
> @@ -145,6 +145,12 @@ New Features
> 
>    * Added support for preferred busy polling.
> 
> +* **Added support of multiple data-units in cryptodev API.**
> +
> +  The cryptodev library has been enhanced to allow operations on
> + multiple  data-units for AES-XTS algorithm, the data-unit length
> + should be set in the  transformation. A capability for it was added too.
> +
>  * **Updated Mellanox RegEx PMD.**
> 
>    * Added support for multi-segments mbuf.
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 9d572ec057..ec45714fc3 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -222,6 +222,19 @@ struct rte_crypto_cipher_xform {
>          *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
>          *  - Both keys must have the same size.
>          **/
> +
> +       uint16_t dataunit_len;
> +       /**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is
> enabled,
> +        * this is the data-unit length of the algorithm,
> +        * otherwise or when the value is 0, use the operation length.
> +        * The value should be in the range defined by the dataunit_set 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 IV.
> +        */
> +
>         struct {
>                 uint16_t offset;
>                 /**< Starting point for Initialisation Vector or Counter, @@ -701,9
> +714,10 @@ struct rte_crypto_sym_op {
>                                          /**< The message length, in bytes, of the
>                                           * source buffer on which the cryptographic
>                                           * operation will be computed.
> +                                         * This is also the same as the result length.
>                                           * This must be a multiple of the block size
> -                                         * if a block cipher is being used. This is
> -                                         * also the same as the result length.
> +                                         * or a multiple of data-unit length
> +                                         * as described in xform.
>                                           *
>                                           * @note
>                                           * For SNOW 3G @
> RTE_CRYPTO_AUTH_SNOW3G_UEA2, diff --git
> a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
> index 40f55a3cd0..e02e001325 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -617,6 +617,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
>                 return "SYM_SESSIONLESS";
>         case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
>                 return "NON_BYTE_ALIGNED_DATA";
> +       case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
> +               return "CIPHER_MULTIPLE_DATA_UNITS";
>         default:
>                 return NULL;
>         }
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index ae34f33f69..f6972a7d19 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -95,6 +95,15 @@ struct rte_crypto_param_range {
>          */
>  };
> 
> +/**
> + * Data-unit supported lengths of cipher algorithms.
> + * A bit can represent any set of data-unit sizes
> + * (single size, multiple size, range, etc).
> + */
> +#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES      (1 << 0)
> +#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES     (1 << 1)
> +#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_1M_BYTES       (1 << 2)

1M is irrelevant since datauinit_len is only 16 bits now.

> +
>  /**
>   * Symmetric Crypto Capability
>   */
> @@ -127,6 +136,11 @@ struct rte_cryptodev_symmetric_capability {
>                         /**< cipher key size range */
>                         struct rte_crypto_param_range iv_size;
>                         /**< Initialisation vector data size range */
> +                       uint32_t dataunit_set;
> +                       /**<
> +                        * A bitmap for a set of the supported data-unit lengths.
> +                        * 0 for any length defined in the algorithm standard.
> +                        */
>                 } cipher;
>                 /**< Symmetric Cipher transform capabilities */
>                 struct {
> @@ -461,6 +475,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> rte_crypto_asym_xform_type *xform_enum,  /**< Support operations on data
> which is not byte aligned */
>  #define RTE_CRYPTODEV_FF_SYM_RAW_DP                    (1ULL << 24)
>  /**< Support accelerator specific symmetric raw data-path APIs */
> +#define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS    (1ULL << 25)
> +/**< Support operations on multiple data-units message */
> 
>  /**
>   * Get the name of a crypto device feature flag
> --
> 2.31.1

[dpdk-dev] [PATCH v4] cryptodev: support multiple cipher data-units

[Thomas Monjalon]

From: Matan Azrad <matan@nvidia.com>

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.

For AES standard the block size is 16 bytes.
For AES in XTS mode, the data to be encrypted\decrypted does not have to
be multiple of 16B size, the unit of data is called data-unit.
The data-unit size can be any size in range [16B, 2^24B], so, in this
case, a data stream is divided into N amount of equal data-units and
must be encrypted\decrypted in the same data-unit resolution.

For ABI compatibility reason, the size is limited to 64K (16-bit field).
The new field dataunit_len is inserted in a struct padding hole,
which is only 2 bytes long in 32-bit build.
It could be moved and extended later during an ABI-breakage window.

The current cryptodev API doesn't allow the user to select a specific
data-unit length supported by the devices.
In addition, there is no definition how the IV is detected per data-unit
when single operation includes more than one data-unit.

That causes applications to use single operation per data-unit even though
all the data is continuous in memory what reduces datapath performance.

Add a new feature flag to support multiple data-unit sizes, called
RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS.
Add a new field in cipher capability, called dataunit_set,
where the devices can report the range of the supported data-unit sizes.
Add a new cipher transformation field, called dataunit_len, where the user
can select the data-unit length for all the operations.

All the new fields do not change the size of their structures,
by filling some struct padding holes.
They are added as exceptions in the ABI check file libabigail.abignore.

Using a bitmap to report the supported data-unit 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
among different devices.

Signed-off-by: Matan Azrad <matan@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v1:
- Use data-unit term instead of block.
- Update cipher length description in OP.
- Improve descriptions on xform and capability.
- Improve commit log.

v2:
- Fix typo: MULITPLE->MULTIPLE.
- Remain only planned supported sizes for data-unit capability.

v3:
- Improve some comments.
- Fix ABI breakage.

v4:
- Remove RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_1M_BYTES
- Fix dataunit_len placement in padding hole
---
 devtools/libabigail.abignore               | 12 ++++++++-
 doc/guides/cryptodevs/features/default.ini |  1 +
 doc/guides/cryptodevs/overview.rst         |  3 +++
 doc/guides/rel_notes/release_21_05.rst     |  6 +++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 29 ++++++++++++++++++++--
 lib/librte_cryptodev/rte_cryptodev.c       |  2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 15 +++++++++++
 7 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 6c0b38984e..bce940f2df 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -19,4 +19,14 @@
 ; Ignore fields inserted in cacheline boundary of rte_cryptodev
 [suppress_type]
         name = rte_cryptodev
-        has_data_member_inserted_between = {offset_after(attached), end}
\ No newline at end of file
+        has_data_member_inserted_between = {offset_after(attached), end}
+
+; Ignore fields inserted in union boundary of rte_cryptodev_symmetric_capability
+[suppress_type]
+        name = rte_cryptodev_symmetric_capability
+        has_data_member_inserted_between = {offset_after(cipher.iv_size), end}
+
+; Ignore fields inserted in middle padding of rte_crypto_cipher_xform
+[suppress_type]
+        name = rte_crypto_cipher_xform
+        has_data_member_inserted_between = {offset_after(key), offset_of(iv)}
diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 17b177fc45..978bb30cc1 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -31,6 +31,7 @@ CPU crypto             =
 Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
+Cipher multiple data units =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e2a1e08ec1..e24e3e1993 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -46,6 +46,9 @@ Supported Feature Flags
    - "Digest encrypted" feature flag means PMD support hash-cipher cases,
      where generated digest is appended to and encrypted with the data.
 
+   - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
+      on multiple data-units message.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 9a666b629d..2dc776c35e 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -145,6 +145,12 @@ New Features
 
   * Added support for preferred busy polling.
 
+* **Added support of multiple data-units in cryptodev API.**
+
+  The cryptodev library has been enhanced to allow operations on multiple
+  data-units for AES-XTS algorithm, the data-unit length should be set in the
+  transformation. A capability for it was added too.
+
 * **Updated Mellanox RegEx PMD.**
 
   * Added support for multi-segments mbuf.
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d572ec057..4e365b1eab 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -195,6 +195,9 @@ struct rte_crypto_cipher_xform {
 	enum rte_crypto_cipher_algorithm algo;
 	/**< Cipher algorithm */
 
+	RTE_STD_C11
+	union { /* temporary anonymous union for ABI compatibility */
+
 	struct {
 		const uint8_t *data;	/**< pointer to key data */
 		uint16_t length;	/**< key length in bytes */
@@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform {
 	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
 	 *  - Both keys must have the same size.
 	 **/
+
+	RTE_STD_C11
+	struct { /* temporary anonymous struct for ABI compatibility */
+		const uint8_t *_key_data; /* reserved for key.data union */
+		uint16_t _key_length;     /* reserved for key.length union */
+		/* next field can fill the padding hole */
+
+	uint16_t dataunit_len;
+	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is enabled,
+	 * this is the data-unit length of the algorithm,
+	 * otherwise or when the value is 0, use the operation length.
+	 * The value should be in the range defined by the dataunit_set 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 IV.
+	 */
+
+	}; }; /* temporary struct nested in union for ABI compatibility */
+
 	struct {
 		uint16_t offset;
 		/**< Starting point for Initialisation Vector or Counter,
@@ -701,9 +725,10 @@ struct rte_crypto_sym_op {
 					 /**< The message length, in bytes, of the
 					  * source buffer on which the cryptographic
 					  * operation will be computed.
+					  * This is also the same as the result length.
 					  * This must be a multiple of the block size
-					  * if a block cipher is being used. This is
-					  * also the same as the result length.
+					  * or a multiple of data-unit length
+					  * as described in xform.
 					  *
 					  * @note
 					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 40f55a3cd0..e02e001325 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -617,6 +617,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
 		return "SYM_SESSIONLESS";
 	case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
 		return "NON_BYTE_ALIGNED_DATA";
+	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
+		return "CIPHER_MULTIPLE_DATA_UNITS";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index ae34f33f69..2508abd6e1 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -95,6 +95,14 @@ struct rte_crypto_param_range {
 	 */
 };
 
+/**
+ * Data-unit supported lengths of cipher algorithms.
+ * A bit can represent any set of data-unit sizes
+ * (single size, multiple size, range, etc).
+ */
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES	(1 << 0)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES	(1 << 1)
+
 /**
  * Symmetric Crypto Capability
  */
@@ -127,6 +135,11 @@ struct rte_cryptodev_symmetric_capability {
 			/**< cipher key size range */
 			struct rte_crypto_param_range iv_size;
 			/**< Initialisation vector data size range */
+			uint32_t dataunit_set;
+			/**<
+			 * A bitmap for a set of the supported data-unit lengths.
+			 * 0 for any length defined in the algorithm standard.
+			 */
 		} cipher;
 		/**< Symmetric Cipher transform capabilities */
 		struct {
@@ -461,6 +474,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support operations on data which is not byte aligned */
 #define RTE_CRYPTODEV_FF_SYM_RAW_DP			(1ULL << 24)
 /**< Support accelerator specific symmetric raw data-path APIs */
+#define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
+/**< Support operations on multiple data-units message */
 
 /**
  * Get the name of a crypto device feature flag
-- 
2.31.1

Re: [dpdk-dev] [EXT] [PATCH v4] cryptodev: support multiple cipher data-units

[Akhil Goyal]

Hi Thomas,

> +	RTE_STD_C11
> +	union { /* temporary anonymous union for ABI compatibility */
> +
>  	struct {
>  		const uint8_t *data;	/**< pointer to key data */
>  		uint16_t length;	/**< key length in bytes */
> @@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform {
>  	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
>  	 *  - Both keys must have the same size.
>  	 **/
> +
> +	RTE_STD_C11
> +	struct { /* temporary anonymous struct for ABI compatibility */
> +		const uint8_t *_key_data; /* reserved for key.data union */
> +		uint16_t _key_length;     /* reserved for key.length union */
> +		/* next field can fill the padding hole */
> +
> +	uint16_t dataunit_len;
> +	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is
> enabled,
> +	 * this is the data-unit length of the algorithm,
> +	 * otherwise or when the value is 0, use the operation length.
> +	 * The value should be in the range defined by the dataunit_set 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 IV.
> +	 */
> +
> +	}; }; /* temporary struct nested in union for ABI compatibility */
> +
Can we add a deprecation notice also in this patch to remove these temporary
Struct and union, so that we remember to remove them in 21.11

> +/**
> + * Data-unit supported lengths of cipher algorithms.
> + * A bit can represent any set of data-unit sizes
> + * (single size, multiple size, range, etc).
> + */
> +#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES	(1 << 0)
> +#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES	(1 << 1)
> +
>  /**
>   * Symmetric Crypto Capability
>   */
> @@ -127,6 +135,11 @@ struct rte_cryptodev_symmetric_capability {
>  			/**< cipher key size range */
>  			struct rte_crypto_param_range iv_size;
>  			/**< Initialisation vector data size range */
> +			uint32_t dataunit_set;
> +			/**<
> +			 * A bitmap for a set of the supported data-unit
> lengths.

Add reference to the newly created macros here

> +			 * 0 for any length defined in the algorithm standard.
> +			 */

Re: [dpdk-dev] [EXT] [PATCH v4] cryptodev: support multiple cipher data-units

[Thomas Monjalon]

14/04/2021 20:37, Akhil Goyal:
> Hi Thomas,
> 
> > +	RTE_STD_C11
> > +	union { /* temporary anonymous union for ABI compatibility */
> > +
> >  	struct {
> >  		const uint8_t *data;	/**< pointer to key data */
> >  		uint16_t length;	/**< key length in bytes */
> > @@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform {
> >  	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
> >  	 *  - Both keys must have the same size.
> >  	 **/
> > +
> > +	RTE_STD_C11
> > +	struct { /* temporary anonymous struct for ABI compatibility */
> > +		const uint8_t *_key_data; /* reserved for key.data union */
> > +		uint16_t _key_length;     /* reserved for key.length union */
> > +		/* next field can fill the padding hole */
> > +
> > +	uint16_t dataunit_len;
> > +	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is
> > enabled,
> > +	 * this is the data-unit length of the algorithm,
> > +	 * otherwise or when the value is 0, use the operation length.
> > +	 * The value should be in the range defined by the dataunit_set 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 IV.
> > +	 */
> > +
> > +	}; }; /* temporary struct nested in union for ABI compatibility */
> > +
> Can we add a deprecation notice also in this patch to remove these temporary
> Struct and union, so that we remember to remove them in 21.11

I thought about it, but a deprecation notice may involve
new design considerations and requires 3 approvals.
I think it is better to send it separately.

> > @@ -127,6 +135,11 @@ struct rte_cryptodev_symmetric_capability {
> >  			/**< cipher key size range */
> >  			struct rte_crypto_param_range iv_size;
> >  			/**< Initialisation vector data size range */
> > +			uint32_t dataunit_set;
> > +			/**<
> > +			 * A bitmap for a set of the supported data-unit
> > lengths.
> 
> Add reference to the newly created macros here
> 
> > +			 * 0 for any length defined in the algorithm standard.
> > +			 */

Yes, I've seen this miss after sending.
I'll reword like this:
  * Supported data-unit lengths:
  * RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_* bits
  * or 0 for lengths defined in the algorithm standard.

Re: [dpdk-dev] [EXT] [PATCH v4] cryptodev: support multiple cipher data-units

[Akhil Goyal]

> 
> 14/04/2021 20:37, Akhil Goyal:
> > Hi Thomas,
> >
> > > +	RTE_STD_C11
> > > +	union { /* temporary anonymous union for ABI compatibility */
> > > +
> > >  	struct {
> > >  		const uint8_t *data;	/**< pointer to key data */
> > >  		uint16_t length;	/**< key length in bytes */
> > > @@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform {
> > >  	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
> > >  	 *  - Both keys must have the same size.
> > >  	 **/
> > > +
> > > +	RTE_STD_C11
> > > +	struct { /* temporary anonymous struct for ABI compatibility */
> > > +		const uint8_t *_key_data; /* reserved for key.data union */
> > > +		uint16_t _key_length;     /* reserved for key.length union */
> > > +		/* next field can fill the padding hole */
> > > +
> > > +	uint16_t dataunit_len;
> > > +	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is
> > > enabled,
> > > +	 * this is the data-unit length of the algorithm,
> > > +	 * otherwise or when the value is 0, use the operation length.
> > > +	 * The value should be in the range defined by the dataunit_set 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 IV.
> > > +	 */
> > > +
> > > +	}; }; /* temporary struct nested in union for ABI compatibility */
> > > +
> > Can we add a deprecation notice also in this patch to remove these
> temporary
> > Struct and union, so that we remember to remove them in 21.11
> 
> I thought about it, but a deprecation notice may involve
> new design considerations and requires 3 approvals.
> I think it is better to send it separately.
In that case you can send it as a separate patch now only.
Just wanted to make sure that it is not forgotten.

> 
> > > @@ -127,6 +135,11 @@ struct rte_cryptodev_symmetric_capability {
> > >  			/**< cipher key size range */
> > >  			struct rte_crypto_param_range iv_size;
> > >  			/**< Initialisation vector data size range */
> > > +			uint32_t dataunit_set;
> > > +			/**<
> > > +			 * A bitmap for a set of the supported data-unit
> > > lengths.
> >
> > Add reference to the newly created macros here
> >
> > > +			 * 0 for any length defined in the algorithm standard.
> > > +			 */
> 
> Yes, I've seen this miss after sending.
> I'll reword like this:
>   * Supported data-unit lengths:
>   * RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_* bits
>   * or 0 for lengths defined in the algorithm standard.

OK

[dpdk-dev] [PATCH] doc: announce extension of crypto data-unit length

[Thomas Monjalon]

The struct member dataunit_len is introduced in DPDK 21.05.
It is limited to 16 bits to fit a padding hole in 32-bit build.
This means the maximum data-unit length is 64 KB.
Some use cases may benefit of a bigger size as the proposed 32 bits.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 doc/guides/rel_notes/deprecation.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 2afc84c396..a17f30c2ff 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -118,6 +118,10 @@ Deprecation Notices
   consistent with existing outer header checksum status flag naming, which
   should help in reducing confusion about its usage.
 
+* cryptodev: The field ``dataunit_len`` of the ``struct rte_crypto_cipher_xform``
+  has a limited size ``uint16_t``.
+  It will be moved and extended as ``uint32_t`` in DPDK 21.11.
+
 * eventdev: The structure ``rte_event_eth_rx_adapter_queue_conf`` will be
   extended to include ``rte_event_eth_rx_adapter_event_vector_config`` elements
   and the function ``rte_event_eth_rx_adapter_queue_event_vector_config`` will
-- 
2.31.1

Re: [dpdk-dev] [EXT] [PATCH v4] cryptodev: support multiple cipher data-units

[Thomas Monjalon]

14/04/2021 21:43, Akhil Goyal:
> > 14/04/2021 20:37, Akhil Goyal:
> > > Hi Thomas,
> > >
> > > > +	RTE_STD_C11
> > > > +	union { /* temporary anonymous union for ABI compatibility */
> > > > +
> > > >  	struct {
> > > >  		const uint8_t *data;	/**< pointer to key data */
> > > >  		uint16_t length;	/**< key length in bytes */
> > > > @@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform {
> > > >  	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
> > > >  	 *  - Both keys must have the same size.
> > > >  	 **/
> > > > +
> > > > +	RTE_STD_C11
> > > > +	struct { /* temporary anonymous struct for ABI compatibility */
> > > > +		const uint8_t *_key_data; /* reserved for key.data union */
> > > > +		uint16_t _key_length;     /* reserved for key.length union */
> > > > +		/* next field can fill the padding hole */
> > > > +
> > > > +	uint16_t dataunit_len;
> > > > +	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is
> > > > enabled,
> > > > +	 * this is the data-unit length of the algorithm,
> > > > +	 * otherwise or when the value is 0, use the operation length.
> > > > +	 * The value should be in the range defined by the dataunit_set 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 IV.
> > > > +	 */
> > > > +
> > > > +	}; }; /* temporary struct nested in union for ABI compatibility */
> > > > +
> > > Can we add a deprecation notice also in this patch to remove these
> > temporary
> > > Struct and union, so that we remember to remove them in 21.11
> > 
> > I thought about it, but a deprecation notice may involve
> > new design considerations and requires 3 approvals.
> > I think it is better to send it separately.
> 
> In that case you can send it as a separate patch now only.
> Just wanted to make sure that it is not forgotten.

Yes, sent:
https://patches.dpdk.org/project/dpdk/patch/20210414201544.1063413-1-thomas@monjalon.net/

[dpdk-dev] [PATCH v5] cryptodev: support multiple cipher data-units

[Thomas Monjalon]

From: Matan Azrad <matan@nvidia.com>

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.

For AES standard the block size is 16 bytes.
For AES in XTS mode, the data to be encrypted\decrypted does not have to
be multiple of 16B size, the unit of data is called data-unit.
The data-unit size can be any size in range [16B, 2^24B], so, in this
case, a data stream is divided into N amount of equal data-units and
must be encrypted\decrypted in the same data-unit resolution.

For ABI compatibility reason, the size is limited to 64K (16-bit field).
The new field dataunit_len is inserted in a struct padding hole,
which is only 2 bytes long in 32-bit build.
It could be moved and extended later during an ABI-breakage window.

The current cryptodev API doesn't allow the user to select a specific
data-unit length supported by the devices.
In addition, there is no definition how the IV is detected per data-unit
when single operation includes more than one data-unit.

That causes applications to use single operation per data-unit even though
all the data is continuous in memory what reduces datapath performance.

Add a new feature flag to support multiple data-unit sizes, called
RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS.
Add a new field in cipher capability, called dataunit_set,
where the devices can report the range of the supported data-unit sizes.
Add a new cipher transformation field, called dataunit_len, where the user
can select the data-unit length for all the operations.

All the new fields do not change the size of their structures,
by filling some struct padding holes.
They are added as exceptions in the ABI check file libabigail.abignore.

Using a bitmap to report the supported data-unit 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
among different devices.

Signed-off-by: Matan Azrad <matan@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v1:
- Use data-unit term instead of block.
- Update cipher length description in OP.
- Improve descriptions on xform and capability.
- Improve commit log.

v2:
- Fix typo: MULITPLE->MULTIPLE.
- Remain only planned supported sizes for data-unit capability.

v3:
- Improve some comments.
- Fix ABI breakage.

v4:
- Remove RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_1M_BYTES
- Fix dataunit_len placement in padding hole

v5:
- Improve comments
- Use RTE_BIT32

deprecation notice:
https://patches.dpdk.org/project/dpdk/patch/20210414201544.1063413-1-thomas@monjalon.net/
---
 devtools/libabigail.abignore               | 12 ++++++++-
 doc/guides/cryptodevs/features/default.ini |  1 +
 doc/guides/cryptodevs/overview.rst         |  3 +++
 doc/guides/rel_notes/release_21_05.rst     |  6 +++++
 lib/librte_cryptodev/rte_crypto_sym.h      | 29 ++++++++++++++++++++--
 lib/librte_cryptodev/rte_cryptodev.c       |  2 ++
 lib/librte_cryptodev/rte_cryptodev.h       | 16 ++++++++++++
 7 files changed, 66 insertions(+), 3 deletions(-)

diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 6c0b38984e..bce940f2df 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -19,4 +19,14 @@
 ; Ignore fields inserted in cacheline boundary of rte_cryptodev
 [suppress_type]
         name = rte_cryptodev
-        has_data_member_inserted_between = {offset_after(attached), end}
\ No newline at end of file
+        has_data_member_inserted_between = {offset_after(attached), end}
+
+; Ignore fields inserted in union boundary of rte_cryptodev_symmetric_capability
+[suppress_type]
+        name = rte_cryptodev_symmetric_capability
+        has_data_member_inserted_between = {offset_after(cipher.iv_size), end}
+
+; Ignore fields inserted in middle padding of rte_crypto_cipher_xform
+[suppress_type]
+        name = rte_crypto_cipher_xform
+        has_data_member_inserted_between = {offset_after(key), offset_of(iv)}
diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 17b177fc45..978bb30cc1 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -31,6 +31,7 @@ CPU crypto             =
 Symmetric sessionless  =
 Non-Byte aligned data  =
 Sym raw data path API  =
+Cipher multiple data units =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index e2a1e08ec1..e24e3e1993 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -46,6 +46,9 @@ Supported Feature Flags
    - "Digest encrypted" feature flag means PMD support hash-cipher cases,
      where generated digest is appended to and encrypted with the data.
 
+   - "CIPHER_MULTIPLE_DATA_UNITS" feature flag means PMD support operations
+      on multiple data-units message.
+
 
 Supported Cipher Algorithms
 ---------------------------
diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst
index 2e3bf5c95a..57b2744d1d 100644
--- a/doc/guides/rel_notes/release_21_05.rst
+++ b/doc/guides/rel_notes/release_21_05.rst
@@ -150,6 +150,12 @@ New Features
 
   * Added support for preferred busy polling.
 
+* **Added support of multiple data-units in cryptodev API.**
+
+  The cryptodev library has been enhanced to allow operations on multiple
+  data-units for AES-XTS algorithm, the data-unit length should be set in the
+  transformation. A capability for it was added too.
+
 * **Updated Mellanox RegEx PMD.**
 
   * Added support for multi-segments mbuf.
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9d572ec057..4e365b1eab 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -195,6 +195,9 @@ struct rte_crypto_cipher_xform {
 	enum rte_crypto_cipher_algorithm algo;
 	/**< Cipher algorithm */
 
+	RTE_STD_C11
+	union { /* temporary anonymous union for ABI compatibility */
+
 	struct {
 		const uint8_t *data;	/**< pointer to key data */
 		uint16_t length;	/**< key length in bytes */
@@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform {
 	 *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
 	 *  - Both keys must have the same size.
 	 **/
+
+	RTE_STD_C11
+	struct { /* temporary anonymous struct for ABI compatibility */
+		const uint8_t *_key_data; /* reserved for key.data union */
+		uint16_t _key_length;     /* reserved for key.length union */
+		/* next field can fill the padding hole */
+
+	uint16_t dataunit_len;
+	/**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is enabled,
+	 * this is the data-unit length of the algorithm,
+	 * otherwise or when the value is 0, use the operation length.
+	 * The value should be in the range defined by the dataunit_set 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 IV.
+	 */
+
+	}; }; /* temporary struct nested in union for ABI compatibility */
+
 	struct {
 		uint16_t offset;
 		/**< Starting point for Initialisation Vector or Counter,
@@ -701,9 +725,10 @@ struct rte_crypto_sym_op {
 					 /**< The message length, in bytes, of the
 					  * source buffer on which the cryptographic
 					  * operation will be computed.
+					  * This is also the same as the result length.
 					  * This must be a multiple of the block size
-					  * if a block cipher is being used. This is
-					  * also the same as the result length.
+					  * or a multiple of data-unit length
+					  * as described in xform.
 					  *
 					  * @note
 					  * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 40f55a3cd0..e02e001325 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -617,6 +617,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
 		return "SYM_SESSIONLESS";
 	case RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA:
 		return "NON_BYTE_ALIGNED_DATA";
+	case RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS:
+		return "CIPHER_MULTIPLE_DATA_UNITS";
 	default:
 		return NULL;
 	}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index ae34f33f69..7e80f4be26 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -95,6 +95,14 @@ struct rte_crypto_param_range {
 	 */
 };
 
+/**
+ * Data-unit supported lengths of cipher algorithms.
+ * A bit can represent any set of data-unit sizes
+ * (single size, multiple size, range, etc).
+ */
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_512_BYTES             RTE_BIT32(0)
+#define RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_4096_BYTES            RTE_BIT32(1)
+
 /**
  * Symmetric Crypto Capability
  */
@@ -127,6 +135,12 @@ struct rte_cryptodev_symmetric_capability {
 			/**< cipher key size range */
 			struct rte_crypto_param_range iv_size;
 			/**< Initialisation vector data size range */
+			uint32_t dataunit_set;
+			/**<
+			 * Supported data-unit lengths:
+			 * RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_* bits
+			 * or 0 for lengths defined in the algorithm standard.
+			 */
 		} cipher;
 		/**< Symmetric Cipher transform capabilities */
 		struct {
@@ -461,6 +475,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
 /**< Support operations on data which is not byte aligned */
 #define RTE_CRYPTODEV_FF_SYM_RAW_DP			(1ULL << 24)
 /**< Support accelerator specific symmetric raw data-path APIs */
+#define RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS	(1ULL << 25)
+/**< Support operations on multiple data-units message */
 
 /**
  * Get the name of a crypto device feature flag
-- 
2.31.1

Re: [dpdk-dev] [EXT] [PATCH v5] cryptodev: support multiple cipher data-units

[Akhil Goyal]

> From: Matan Azrad <matan@nvidia.com>
> 
> 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.
> 
> For AES standard the block size is 16 bytes.
> For AES in XTS mode, the data to be encrypted\decrypted does not have to
> be multiple of 16B size, the unit of data is called data-unit.
> The data-unit size can be any size in range [16B, 2^24B], so, in this
> case, a data stream is divided into N amount of equal data-units and
> must be encrypted\decrypted in the same data-unit resolution.
> 
> For ABI compatibility reason, the size is limited to 64K (16-bit field).
> The new field dataunit_len is inserted in a struct padding hole,
> which is only 2 bytes long in 32-bit build.
> It could be moved and extended later during an ABI-breakage window.
> 
> The current cryptodev API doesn't allow the user to select a specific
> data-unit length supported by the devices.
> In addition, there is no definition how the IV is detected per data-unit
> when single operation includes more than one data-unit.
> 
> That causes applications to use single operation per data-unit even though
> all the data is continuous in memory what reduces datapath performance.
> 
> Add a new feature flag to support multiple data-unit sizes, called
> RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS.
> Add a new field in cipher capability, called dataunit_set,
> where the devices can report the range of the supported data-unit sizes.
> Add a new cipher transformation field, called dataunit_len, where the user
> can select the data-unit length for all the operations.
> 
> All the new fields do not change the size of their structures,
> by filling some struct padding holes.
> They are added as exceptions in the ABI check file libabigail.abignore.
> 
> Using a bitmap to report the supported data-unit 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
> among different devices.
> 
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>

Re: [dpdk-dev] [EXT] [PATCH v5] cryptodev: support multiple cipher data-units

[Akhil Goyal]

> > From: Matan Azrad <matan@nvidia.com>
> >
> > 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.
> >
> > For AES standard the block size is 16 bytes.
> > For AES in XTS mode, the data to be encrypted\decrypted does not have to
> > be multiple of 16B size, the unit of data is called data-unit.
> > The data-unit size can be any size in range [16B, 2^24B], so, in this
> > case, a data stream is divided into N amount of equal data-units and
> > must be encrypted\decrypted in the same data-unit resolution.
> >
> > For ABI compatibility reason, the size is limited to 64K (16-bit field).
> > The new field dataunit_len is inserted in a struct padding hole,
> > which is only 2 bytes long in 32-bit build.
> > It could be moved and extended later during an ABI-breakage window.
> >
> > The current cryptodev API doesn't allow the user to select a specific
> > data-unit length supported by the devices.
> > In addition, there is no definition how the IV is detected per data-unit
> > when single operation includes more than one data-unit.
> >
> > That causes applications to use single operation per data-unit even though
> > all the data is continuous in memory what reduces datapath performance.
> >
> > Add a new feature flag to support multiple data-unit sizes, called
> > RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS.
> > Add a new field in cipher capability, called dataunit_set,
> > where the devices can report the range of the supported data-unit sizes.
> > Add a new cipher transformation field, called dataunit_len, where the user
> > can select the data-unit length for all the operations.
> >
> > All the new fields do not change the size of their structures,
> > by filling some struct padding holes.
> > They are added as exceptions in the ABI check file libabigail.abignore.
> >
> > Using a bitmap to report the supported data-unit 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
> > among different devices.
> >
> > Signed-off-by: Matan Azrad <matan@nvidia.com>
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> Acked-by: Akhil Goyal <gakhil@marvell.com>

Applied to dpdk-next-crypto

This patch is causing ABI breakage at my end, but since CI is passing, I am applying this patch.
I believe my libabigail version is older than what CI is using.

@thomas : Please pull crypto tree to main and send the dependent patches again so that CI can run on them.

Regards,
Akhil

Re: [dpdk-dev] [EXT] [PATCH v5] cryptodev: support multiple cipher data-units

[David Marchand]

On Thu, Apr 15, 2021 at 9:01 PM Akhil Goyal <gakhil@marvell.com> wrote:
> This patch is causing ABI breakage at my end, but since CI is passing, I am applying this patch.
> I believe my libabigail version is older than what CI is using.

I discussed this earlier with Thomas.
This is likely the use of anonymous struct/union that was not
understood by libabigail until recently.

The public CI (Travis and GHA) uses libabigail 1.8.


-- 
David Marchand

Re: [dpdk-dev] [EXT] [PATCH] doc: announce extension of crypto data-unit length

[Akhil Goyal]

> The struct member dataunit_len is introduced in DPDK 21.05.
> It is limited to 16 bits to fit a padding hole in 32-bit build.
> This means the maximum data-unit length is 64 KB.
> Some use cases may benefit of a bigger size as the proposed 32 bits.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>

Thomas,
Please take this patch directly on main, if it gets the required Acks.

Re: [dpdk-dev] [EXT] [PATCH] doc: announce extension of crypto data-unit length

[Thomas Monjalon]

Ping for more votes.
Please ack or reject.

17/05/2021 21:41, Akhil Goyal:
> > The struct member dataunit_len is introduced in DPDK 21.05.
> > It is limited to 16 bits to fit a padding hole in 32-bit build.
> > This means the maximum data-unit length is 64 KB.
> > Some use cases may benefit of a bigger size as the proposed 32 bits.
> > 
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> 
> Thomas,
> Please take this patch directly on main, if it gets the required Acks.

Re: [dpdk-dev] [PATCH] doc: announce extension of crypto data-unit length

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Wed, Apr 14, 2021 at 1:15 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> The struct member dataunit_len is introduced in DPDK 21.05.
> It is limited to 16 bits to fit a padding hole in 32-bit build.
> This means the maximum data-unit length is 64 KB.
> Some use cases may benefit of a bigger size as the proposed 32 bits.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 2afc84c396..a17f30c2ff 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -118,6 +118,10 @@ Deprecation Notices
>    consistent with existing outer header checksum status flag naming, which
>    should help in reducing confusion about its usage.
>
> +* cryptodev: The field ``dataunit_len`` of the ``struct rte_crypto_cipher_xform``
> +  has a limited size ``uint16_t``.
> +  It will be moved and extended as ``uint32_t`` in DPDK 21.11.
> +
>  * eventdev: The structure ``rte_event_eth_rx_adapter_queue_conf`` will be
>    extended to include ``rte_event_eth_rx_adapter_event_vector_config`` elements
>    and the function ``rte_event_eth_rx_adapter_queue_event_vector_config`` will
> --
> 2.31.1
>

Re: [dpdk-dev] [PATCH] doc: announce extension of crypto data-unit length

[Matan Azrad]

From: Thomas Monjalon
> The struct member dataunit_len is introduced in DPDK 21.05.
> It is limited to 16 bits to fit a padding hole in 32-bit build.
> This means the maximum data-unit length is 64 KB.
> Some use cases may benefit of a bigger size as the proposed 32 bits.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Matan Azrad <matan@nvidia.com>

Re: [dpdk-dev] [PATCH] doc: announce extension of crypto data-unit length

[Thomas Monjalon]

14/04/2021 22:15, Thomas Monjalon:
> The struct member dataunit_len is introduced in DPDK 21.05.
> It is limited to 16 bits to fit a padding hole in 32-bit build.
> This means the maximum data-unit length is 64 KB.
> Some use cases may benefit of a bigger size as the proposed 32 bits.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

    Acked-by: Akhil Goyal <gakhil@marvell.com>
    Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
    Acked-by: Matan Azrad <matan@nvidia.com>

Applied