From: Matan Azrad <matan@nvidia.com>
To: "Zhang, Roy Fan" <roy.fan.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "akhil.goyal@nxp.com" <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>,
"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] [RFC] cryptodev: support multiple cipher block sizes
Date: Sun, 7 Feb 2021 06:52:20 +0000 [thread overview]
Message-ID: <MW2PR12MB2492FB0C34D699CE94ECBFC1DFB09@MW2PR12MB2492.namprd12.prod.outlook.com> (raw)
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
reply other threads:[~2021-02-07 6:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MW2PR12MB2492FB0C34D699CE94ECBFC1DFB09@MW2PR12MB2492.namprd12.prod.outlook.com \
--to=matan@nvidia.com \
--cc=adwivedi@marvell.com \
--cc=ajit.khaparde@broadcom.com \
--cc=akhil.goyal@nxp.com \
--cc=anoobj@marvell.com \
--cc=asomalap@amd.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=g.singh@nxp.com \
--cc=jianjay.zhou@huawei.com \
--cc=john.griffin@intel.com \
--cc=michaelsh@marvell.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=rnagadheeraj@marvell.com \
--cc=roy.fan.zhang@intel.com \
--cc=ruifeng.wang@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).