From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id BF5EAA034F;
	Fri, 26 Feb 2021 06:01:29 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 3B6C9407FF;
	Fri, 26 Feb 2021 06:01:29 +0100 (CET)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com
 [67.231.156.173])
 by mails.dpdk.org (Postfix) with ESMTP id A4B6040692
 for <dev@dpdk.org>; Fri, 26 Feb 2021 06:01:27 +0100 (CET)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1])
 by mx0b-0016f401.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id
 11Q50HHe028008; Thu, 25 Feb 2021 21:01:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;
 h=from : to : cc :
 subject : date : message-id : references : in-reply-to : content-type :
 content-transfer-encoding : mime-version; s=pfpt0220;
 bh=PdLnh40LPRhmJjugeqw+fY46LpWiVLEsS6snILEu17k=;
 b=RLw1a3G7ti9oY5R82JSQ+R9qaMr9cADyiV779dO73q16Xx0Zl59cUJdQapXTbgzsfdDU
 DGGsz+sWoQjh8D15TNPmXNwg73uHi4KRXJlV69T1ROiW6G/hww+jQrKZ0V3x7aYbVvD/
 c8eD7jgQomVw5iQFsFoNer9LtOw6AvHzLPU9JoKYBvGsKQa0VKQFVfYgXL1Ld2EBFDT+
 TEPkkrCU8sxF/3nJXCDgs3OP0Sp3fwA+0wMGA46zhNe0EM+lCNjPGgresXiH4TEiCk+i
 BnpbeV9/VG6c7F1XH0yKI47e/gBDB0BV8k3agb1cn8MIxthbahbofWErG7YwmSx8owMR PA== 
Received: from dc5-exch01.marvell.com ([199.233.59.181])
 by mx0b-0016f401.pphosted.com with ESMTP id 36wxbwvn36-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
 Thu, 25 Feb 2021 21:01:21 -0800
Received: from SC-EXCH03.marvell.com (10.93.176.83) by DC5-EXCH01.marvell.com
 (10.69.176.38) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
 Thu, 25 Feb 2021 21:01:19 -0800
Received: from DC5-EXCH01.marvell.com (10.69.176.38) by SC-EXCH03.marvell.com
 (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2;
 Thu, 25 Feb 2021 21:01:19 -0800
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.177)
 by DC5-EXCH01.marvell.com (10.69.176.38) with Microsoft SMTP Server (TLS) id
 15.0.1497.2 via Frontend Transport; Thu, 25 Feb 2021 21:01:18 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=GvEZDeF281mh9Qsk2lNDXAqy5iIAZHZjb1yYVYqFdTYdk+Y74Rx+0YsBbJLKCuahPqc/C6uq9LCNlVkKK6ooyrkNHGMgSq6ldM5wS1KU1ovTlzbR3QakvhygbP6eXq7IRFs0+ghpg5WIM1uIrcfigkLWBvZyo2srmCHluckorxsG6rfosTgSEnbNL62JrRI9kAszfk63WgRw4Rg8EpfEsU4nqb9yZ5+jCD91KfG6gZf9FrAdvaEgh6V/Y1m+YVlCRB6ayjnc3NHoGZTKQHCMNroaI0HmN2/7tJiu6JXsVTle2K4Wmau9v05qzLyj3nxt7YxXz2eCLQe5ZOJhCH1CRw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PdLnh40LPRhmJjugeqw+fY46LpWiVLEsS6snILEu17k=;
 b=cYg56NVvnhZSPwd7fYt/6AIZePyJuuiQxYZ+er9SwOY79x6jqbOsJDQnnUl9eadSa4MzHRU1Wu2RWxgMQxXL68ep9Fas3/gU9AkPceh0U6/G5zUkNM9LvXMrme2SQ3lC4QzytIjHqTD4VXswm+M14FQqWpUGHVxXE/bBnjl+GTGtkRSpBmxwmU9qTlGB56ZSFK6Z6WwZx0nL+8mjoOPH1kliAaPVEa4HWm0rYo/AIk0OoAngLoaWn/bxuZocbgIdpRn5eGst8UK7tXAeM5ldgXlh3Bl+6/hLbNhDhbUtaRsE/je+ishvIP3JuUvu6d7LY3uZYz+ETlmNq1gGpyLRGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com;
 dkim=pass header.d=marvell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=PdLnh40LPRhmJjugeqw+fY46LpWiVLEsS6snILEu17k=;
 b=Gu+kx0MfKR5KD/CUkKJIMdlBgndYxaADlKbWiNTOwi1K7FOEnsqxU2QaBOJQh3fh1bn2pGRHiscZsnKwYEr1tmKgcv2XFMiWRDPK4gHNmJsY1Gf0cWF9bEjXav/1sdtTCu4oEnaiGwbGBFNv5Ov4sADaeUJElaY7g0rS1JW721s=
Received: from MWHPR18MB1168.namprd18.prod.outlook.com (2603:10b6:300:a6::12)
 by MWHPR18MB1424.namprd18.prod.outlook.com (2603:10b6:320:2c::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.33; Fri, 26 Feb
 2021 05:01:15 +0000
Received: from MWHPR18MB1168.namprd18.prod.outlook.com
 ([fe80::dcab:e526:10f4:b437]) by MWHPR18MB1168.namprd18.prod.outlook.com
 ([fe80::dcab:e526:10f4:b437%6]) with mapi id 15.20.3890.022; Fri, 26 Feb 2021
 05:01:15 +0000
From: Anoob Joseph <anoobj@marvell.com>
To: Matan Azrad <matan@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: Declan Doherty <declan.doherty@intel.com>, Somalapuram Amaranath
 <asomalap@amd.com>, Ruifeng Wang <ruifeng.wang@arm.com>, Ajit Khaparde
 <ajit.khaparde@broadcom.com>, Fan Zhang <roy.fan.zhang@intel.com>, "John
 Griffin" <john.griffin@intel.com>, Pablo de Lara
 <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>, Akhil Goyal <gakhil@marvell.com>, "Jerin Jacob
 Kollanukkaran" <jerinj@marvell.com>
Thread-Topic: [EXT] [PATCH] cryptodev: support multiple cipher block sizes
Thread-Index: AQHW+wLf0yv335b8QkWqE7I+84R4Fapp95fA
Date: Fri, 26 Feb 2021 05:01:15 +0000
Message-ID: <MWHPR18MB11682C7E16206EDF52F1AACBDF9D9@MWHPR18MB1168.namprd18.prod.outlook.com>
References: <1612449252-395208-1-git-send-email-matan@nvidia.com>
In-Reply-To: <1612449252-395208-1-git-send-email-matan@nvidia.com>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: nvidia.com; dkim=none (message not signed)
 header.d=none;nvidia.com; dmarc=none action=none header.from=marvell.com;
x-originating-ip: [157.44.181.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b646f759-6ea1-460f-6a42-08d8da138bdb
x-ms-traffictypediagnostic: MWHPR18MB1424:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR18MB142458D42D50ABE604A18FA5DF9D9@MWHPR18MB1424.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CWBqkYstFhyi+o7sk9LmnVFfipw6jCIz3XKHGiiipLXak+RgVkkAehU8rNhFxchVoFS7AxqMv4Sf/4mtkSm5tqd0n2B0W0HLp+DFaZTl3xSbAT4EUfphG5zlf0VUae7pZLn++dczjAd4nYTPSiSqxVlgyZ/A7yq4Q2/LuKeClpSkbledeVqRKUw6gLr9AfCiffb011oh2T9I2IqYRvfQq28iDARmljQ1oWDeUy57n0Zrg5yHxRXEcr+R1i91LF+rjj4oFz2NzoLP4RJprIsa7Puegb+KcYuZdtE7fhXVEifCbx/T5N14x4qKwjigMIRY+15VU3NX96JfF/O6+cv7bHZ4R1weuOINppxs7rZ5ONyWAP6LouAp2gbhNxKqAm3kVjMDTEc0Zn/97cQ3I7w9FwnS2GYeG7bqgcFKR1GgB+HXOuprLH3z4j8YUpSRLPe/0fGw9EWZUhaBW4pQRs3hAJfKkoZQ9byg8WIdAIya3w4cxCnCUj8r2E8ziA/w710swCsLgzGJEZED493DXmNPoQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:MWHPR18MB1168.namprd18.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(4636009)(346002)(366004)(376002)(39860400002)(136003)(396003)(66476007)(64756008)(66446008)(66556008)(33656002)(66946007)(76116006)(7416002)(5660300002)(52536014)(186003)(53546011)(71200400001)(4326008)(86362001)(26005)(2906002)(316002)(6506007)(54906003)(8676002)(83380400001)(110136005)(107886003)(478600001)(7696005)(8936002)(9686003)(55016002);
 DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?9r2DOnONScTllCdIhPASw+pj144kbKB2oYQaGPbdhyUaN0JIU5fUFOIFqJYM?=
 =?us-ascii?Q?ihHLdhmC41q14VP4RfpYEHGabLPykVO4m7F/XKSZud8yNf7oYG4jqKK+WkLO?=
 =?us-ascii?Q?tPCAeqacalyqkSEIGT0ZzNmUd92beL5EU6YlrOAQTFbGC1nK1i8BAlnfVdhS?=
 =?us-ascii?Q?2rpM/X/8wbmtau0jW+NFL2yccVzn1baUpsTqGx5hdtAHCEVM6XlwGIGKGBVE?=
 =?us-ascii?Q?2Hk98lMFyKLDohaCamcViU03S/fdRA25BDIUsFXViwcRpNmhW/vnICnDxZM5?=
 =?us-ascii?Q?R/brCQgr7ePvwNONT8W4UyDaWypkHUF5EqoXL+yht3Jozwymz9J83KSHi0Xn?=
 =?us-ascii?Q?A64fGGQ8kYfew2qsp0iIV1SsIeKgea09lZoxRPJIp3vS+YWmTfuNn7ruqKHl?=
 =?us-ascii?Q?8hoPO5Tu/rNvgA7x1KALGadZ7iE160PH9T2+rZk6hjXbbhEMrK37R0Zd88if?=
 =?us-ascii?Q?PGB02/Hg+a33EbaqfcOmzvQIcwmu+8b3jhinOFv2kZoWtol3Z3Nui9Fl4NPn?=
 =?us-ascii?Q?u3dPA4t0fjlL4j6IA4MR74mRalCRl/bVdfeqmHJhKtjR7wUyTuSwVziMspku?=
 =?us-ascii?Q?oPc91jL5I6dACsjlz9PKHQXx0nr71KlZ24xGmM8652xNBTywph4yyeTk9uhx?=
 =?us-ascii?Q?+zvsaKEba/0cwmvhZixTQW6QqD63AycXFsdzJTmEOdTUhUc7LL8wiULcepxD?=
 =?us-ascii?Q?d5YVhvGYCAAAw73zd9PKbV0Qm3k36qBEUoEim+TX+CRC2nK7/xndF5nGoiTK?=
 =?us-ascii?Q?pe/fbsPv/7wY3RYeur9LoA4UjHgXrjFU+xbEH1R0r513MsPbykz3G9qadZui?=
 =?us-ascii?Q?bDKILvJuByP0L692BVO+j/2WlecTsUrw54oM3++A0BOhctd2m0vAwSpYZMlK?=
 =?us-ascii?Q?p7cc65//OOIvewGjzgwc8ZTlTXchPXb4WOVKf1wisTipXDkeMAPogjlhQhaK?=
 =?us-ascii?Q?aj/5deK8qa76xPwWlaHR+AmyMC3mw1717O+2rULvKwRtIkV48SP3KG/lchso?=
 =?us-ascii?Q?IG5erz4/2AZKkKus854+CWFEu3fgNUFOwr/UaJt/sl7O+lkDgVlRrFc/2epX?=
 =?us-ascii?Q?IVHm3mUZLUeclpY+IiL6QqN8sBIX+kLrjj6kNic8GxYrpskflvwNcUbq+EU3?=
 =?us-ascii?Q?JDlRPib/c54kDCDLB5jY7GVekn0ZOfVgzhHvgofx73Oo8FblMc1fcenxJuta?=
 =?us-ascii?Q?Ooiwe886ouT3OiF8tAKPC+iwZKX9RKc4WJpnTyayCV11z7OMON1hscVlCZCc?=
 =?us-ascii?Q?Y3uXjcd7S+BtG5IIMTwmhTfB4Wn2a5RQ6/U9hwAYkn7tjYWetA4YIgkG2Xry?=
 =?us-ascii?Q?UfRjDy/3x+hzsqWejj79ZeCb?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR18MB1168.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b646f759-6ea1-460f-6a42-08d8da138bdb
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 05:01:15.6272 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 95UYMGpwmoQ82tB2QzVPygdPk/btAcHSj/YBTc7nPXybmY1sdfUp3d5bJ2fBpoKIanNiUV/VRWoiZmW6VFJ5pw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR18MB1424
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761
 definitions=2021-02-26_01:2021-02-24,
 2021-02-26 signatures=0
Subject: Re: [dpdk-dev] [EXT] [PATCH] cryptodev: support multiple cipher
 block sizes
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Matan,

With the current spec, AES-XTS operation offloading would mean application =
is expected to track data blocks and the corresponding tweak & cipher steal=
ing, while the final crypto operation gets offloaded to PMD. This proposal =
aims at moving the entire AES-XTS operation (including tweak update) to PMD=
. Did I understand the proposal right?

If yes, I believe this is a good feature to be added. But I've few question=
s,

1. Who is responsible for cipher stealing? Do we expect PMD to pad the fina=
l data unit?
2. If we treat AES-XTS as an operation for just encrypting and decrypting a=
 large blob of data, the current proposal would be good enough. But often, =
AES-XTS is used in disk encryption where selected pages are updated without=
 requiring the entire disk to be decrypted (& encrypted after). Did you con=
sider if we could extend the spec to support such a use case also? (Agreed =
that we could do page updates by handling tweak etc from application as is =
being done now).
3. On top level, this requirement has similarities to rte_security. Did you=
 consider that route?

Thanks,
Anoob

> -----Original Message-----
> From: Matan Azrad <matan@nvidia.com>
> Sent: Thursday, February 4, 2021 8:04 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Declan Doherty <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>; Fan Zhang
> <roy.fan.zhang@intel.com>; John Griffin <john.griffin@intel.com>; Pablo d=
e
> Lara <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: [EXT] [PATCH] cryptodev: support multiple cipher block sizes
>=20
> External Email
>=20
> ----------------------------------------------------------------------
> In cryptography, a block cipher is a deterministic algorithm operating on
> fixed-length groups of bits, called blocks.
>=20
> 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 funct=
ion
> of the encryption.
>=20
> Some cipher algorithms support multiple block sizes, e.g. AES-XTS support=
s
> any block size in range [16B, 2^24B], in this case, A plain-text data, di=
vided
> into N amount of n-bits blocks, which is encrypted to the same data size,
> cipher-text, must be decrypted in the same division of N amount of n-bits
> blocks in order to get the same plain-text data.
>=20
> The current cryptodev API doesn't allow the user to select a specific blo=
ck
> size supported by the devices In addition, there is no definition how the=
 IV is
> detected per block when single operation includes more than one block.
>=20
> That causes applications to use single operation per block even though al=
l the
> data is continuous in memory what reduces datapath performance.
>=20
> Add a new feature flag to support multiple block sizes, called
> RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS.
> Add a new field in cipher capability, called bsf - block size flags, wher=
e the
> devices can report the range of the supported block sizes.
> Add a new cipher transformation field, called block_size, where the user =
can
> select one block size from the supported range.
>=20
> All the new fields do not change the size of their structures.
>=20
> Using flags to report the supported block sizes capability allows the dev=
ices
> 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 between t=
he
> devices.
>=20
> Signed-off-by: Matan Azrad <matan@nvidia.com>
> ---
>  lib/librte_cryptodev/rte_crypto_sym.h | 12 ++++++++++++
> lib/librte_cryptodev/rte_cryptodev.h  | 23 ++++++++++++++++++++++-
>  2 files changed, 34 insertions(+), 1 deletion(-)
>=20
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
> b/lib/librte_cryptodev/rte_crypto_sym.h
> index 9d572ec..9a1215d 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -265,6 +265,18 @@ struct rte_crypto_cipher_xform {
>  		 * which can be in the range 7 to 13 inclusive.
>  		 */
>  	} iv;	/**< Initialisation vector parameters */
> +
> +	uint32_t block_size;
> +	/**< When RTE_CRYPTODEV_FF_CIPHER_MULITPLE_BLOCKS is
> reported, this is
> +	 * the block size of the algorithm, otherwise or when the value is 0,
> +	 * use the default block size provided in the capability.
> +	 * The value should be in the range defined by the bsf field in the
> +	 * cipher capability.
> +	 *
> +	 * - For AES-XTS it is the size of data-unit, from IEEE Std 1619-2007.
> +	 * For-each data-unit in the operation, the tweak(IV) value is
> +	 * assigned consecutively starting from the operation assigned
> tweak.
> +	 */
>  };
>=20
>  /** Symmetric Authentication / Hash Algorithms diff --git
> a/lib/librte_cryptodev/rte_cryptodev.h
> b/lib/librte_cryptodev/rte_cryptodev.h
> index ae34f33..60ba839 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -96,6 +96,19 @@ struct rte_crypto_param_range {  };
>=20
>  /**
> + * Crypto device supported block size flags for cipher algorithms
> + * Each flag represents single or range of supported block sizes  */
> +#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 */
>  		} cipher;
>  		/**< Symmetric Cipher transform capabilities */
>  		struct {
> --
> 1.8.3.1