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

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

[Matan Azrad]

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.

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

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.
> 
> >               } cipher;
> >               /**< Symmetric Cipher transform capabilities */
> >               struct {
> > --
> > 1.8.3.1
> 
> Regards,
> Fan