cryptodev: support multiple cipher data-units

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

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

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.