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

Hi Zhang

Hi Matan,

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

Yes, this is important agreement.

quoted

-----Original Message-----
From: Matan Azrad <redacted>
Sent: Thursday, February 4, 2021 2:34 PM
To: dev@dpdk.org
Cc: akhil.goyal@nxp.com; Doherty, Declan <redacted>;
Somalapuram Amaranath [off-list ref]; Ruifeng Wang
[off-list ref]; Ajit Khaparde [off-list ref];
Anoob Joseph [off-list ref]; Zhang, Roy Fan
[off-list ref]; Griffin, John [off-list ref]; De
Lara Guarch, Pablo [off-list ref]; Michael Shamis
[off-list ref]; Nagadheeraj Rottela
[off-list ref]; Ankur Dwivedi [off-list ref];
Gagandeep Singh [off-list ref]; Jay Zhou [off-list ref]
Subject: [PATCH] cryptodev: support multiple cipher block sizes

[SNIP]

quoted

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

Yes, there are a lot of options for block size combinations, it can be any combination of values from the standard minimum to the standard maximum.
I don't think there is a type that can potentially include all the options classically. 

For example, using `struct rte_crypto_param_range` is not good for PMDs supports values with different increment steps(mlx5).

Do you have other suggestion?

Using bitmap is not so classic but have good advantage:
Any bit can represent one combination, current suggestion is to use any bit as continuous range but actually it can represent any combination, so any PMD can use only 1 bit to represent its own supported combination.

Also, It looks like the values are common per algorithm, am I wrong here?
Due to the fact that the supported combination is different per algorithm,
We can define the bsf values to be different per algorithm.
what do you think?

I though also that a new pmd callback to check if a value \ set of values are supported is good option too.
Here, the application can check if its wanted values are supported or not.
For example: 
The arguments will be a list of values \ a list of value ranges and algorithm and the PMD will return the first value supported for this algorithm in the list.
What do you think?

Also bsf seems to be a duplication to existing block_size.

The existing block size defined to be the PMD default\preferred value for better performance - can be good knowledge for applications.

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

quoted

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

Regards,
Fan