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 <ma...@nvidia.com>
> > Sent: Thursday, February 4, 2021 2:34 PM
> > To: dev@dpdk.org
> > Cc: akhil.go...@nxp.com; Doherty, Declan <declan.dohe...@intel.com>;
> > Somalapuram Amaranath <asoma...@amd.com>; Ruifeng Wang
> > <ruifeng.w...@arm.com>; Ajit Khaparde <ajit.khapa...@broadcom.com>;
> > Anoob Joseph <ano...@marvell.com>; Zhang, Roy Fan
> > <roy.fan.zh...@intel.com>; Griffin, John <john.grif...@intel.com>; De
> > Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Michael Shamis
> > <michae...@marvell.com>; Nagadheeraj Rottela
> > <rnagadhee...@marvell.com>; Ankur Dwivedi <adwiv...@marvell.com>;
> > Gagandeep Singh <g.si...@nxp.com>; Jay Zhou <jianjay.z...@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
