From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9D357A0547; Mon, 8 Feb 2021 14:38:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 239E04014E; Mon, 8 Feb 2021 14:38:14 +0100 (CET) Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) by mails.dpdk.org (Postfix) with ESMTP id 65F6540147 for ; Mon, 8 Feb 2021 14:38:12 +0100 (CET) Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 08 Feb 2021 05:38:11 -0800 Received: from HQMAIL105.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Mon, 08 Feb 2021 05:38:11 -0800 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Mon, 08 Feb 2021 05:38:11 -0800 Received: from HQMAIL111.nvidia.com (172.20.187.18) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Feb 2021 13:38:10 +0000 Received: from HQMAIL109.nvidia.com (172.20.187.15) by HQMAIL111.nvidia.com (172.20.187.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Feb 2021 13:37:00 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.102) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Feb 2021 13:37:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eQG6UEDwNmxSy6At1auWztgpzEouk+039mZzqDR0KNUF1BNE+I/UUXJs0dDeW0vdRlx8jloPntlcWQ+fqknNXoYwiCM1KKz8r0TD1e/apWMRYJWG4Jbfdp6zCkogKwdgs149Com/E23bgp37zY7QueKCqgVB0Desl1SUXjIwq7By0WHeTw79KN+jdsLq9lHWkOkg3sc1N+TkHLLStVhSd7W+KlAilMX6qrfA/BhHRFdygf46y8CHh5TCtyJvLGX+eJ0xXrANkRiuFEGWzhN/RxfHw02p6cBO8rtD9ThflGbo6hHdt1xRsriyIu6BoQ1Bw9FrBk7cV2akDnvSY1ILqg== 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=Wnd3ps0+Ia6SPKmnLG3hZjX2Hdrd1rQcJWll+XmijO0=; b=aEWXoEtfJm8WwIKbFI/KkNb2NaDd1xfPckIgRQH/9al4OOBOkHw0HvfOQGjethQ7bsNVCBOxaePDTaulqmsTrNYevF867+t96Or2k4O25unwG9PhHc7jyI2h5ii5EmmDX0cg9S8cDl23u5QCyzrMb3rPCIr04yzMDBx+93rTY/iWIXYC/lOlwDBJNccLg1CCxsHMJGAFFxRLHJHnKIfMzNSSs3zRt53AbI+1MWt4vnoxIk1ThE323WKsTgv7XeA5p15JmVG9kAmYN+AMwc/gnUdDdwoccBCLemNo9oYCFKBfpLlCQh57XWXy/b5WuHdIbTBsSHZSy7ppXxs6dnIUag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from MW2PR12MB2492.namprd12.prod.outlook.com (2603:10b6:907:8::19) by MWHPR1201MB2478.namprd12.prod.outlook.com (2603:10b6:300:e5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.23; Mon, 8 Feb 2021 13:36:59 +0000 Received: from MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::680b:7b85:ef35:433b]) by MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::680b:7b85:ef35:433b%6]) with mapi id 15.20.3825.030; Mon, 8 Feb 2021 13:36:58 +0000 From: Matan Azrad To: "Kusztal, ArkadiuszX" , "dev@dpdk.org" CC: "akhil.goyal@nxp.com" , "Doherty, Declan" , Somalapuram Amaranath , "Ruifeng Wang" , Ajit Khaparde , Anoob Joseph , "Zhang, Roy Fan" , "Griffin, John" , "De Lara Guarch, Pablo" , Michael Shamis , Nagadheeraj Rottela , Ankur Dwivedi , Gagandeep Singh , "Jay Zhou" Thread-Topic: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block sizes Thread-Index: AQHW+wLiyZS95CeI4k+/3gG8QlAt1qpOMLcAgAAOFXA= Date: Mon, 8 Feb 2021 13:36:58 +0000 Message-ID: References: <1612449252-395208-1-git-send-email-matan@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [216.228.117.190] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27d643fd-2e35-4dbc-d121-08d8cc369bda x-ms-traffictypediagnostic: MWHPR1201MB2478: x-microsoft-antispam-prvs: x-header: ProcessedBy-CMR-outbound x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RQWVwPS+/MRyH4dsGcuhpyxRDSyFUcsj8mLxM+iBaj1NEXxXc1WhRd12JE5QRzcpOg2kTC+dhQfx8IrKFt0GSlIG1psooYIJtqBGy82RubwaI2pOcOn7I6FMU2mpwCLCJwSOu6eNXQkELPRIUndOmN9QG/nbjC4oeIYtc8qBQM8U9sjex5gJI+4NmUsYwbDYWUNt6heyKSsrNe0HJDPueHTO3obaxqn217+tkDoAtB80RLHUVSKOxEZA5BmwJ9cTf0iDl9/r8unlukgoyhp8AOw5RW3XfknHg86kMCEbqYQ4XbwTXM8Sp+FkoznFzuqbjlJRsyCT9lfa5BRiaE3GrIfBCDi5839SC0iVeI/YaOdeKD3VqyfSI/k4ysP515Ub1IdkMwRzcd029HJD8H4AqopD4ZXCcEBerewEsj0+rhMfDVmrfv67e+R5j5Z119cNwcKLSJG+dpKufzTIEIFaO14SmnNu+QzFjV0DsL26Rvb9AYiPRpqJd7e08ALBqx7J3XXC7oRcw22RpIG+2tOJyQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR12MB2492.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(396003)(366004)(136003)(39860400002)(26005)(9686003)(478600001)(2906002)(76116006)(66556008)(64756008)(66446008)(53546011)(7416002)(66946007)(6506007)(316002)(66476007)(33656002)(4326008)(71200400001)(8936002)(83380400001)(8676002)(186003)(55016002)(86362001)(5660300002)(54906003)(7696005)(110136005)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?GjCxK+6S3B2sAQ50x1ARbDAZApM/vmQ7X8DqPDWhZdDNOXeIwmAyWtKnCHDU?= =?us-ascii?Q?1qkx+oxYJ02HJs70ZIYPn2hUHU8yq+DikhHlOx/CdNfI5ouvhEFv+UxR/aFP?= =?us-ascii?Q?wN4F2peX19O8wh+iJkGvHF2fmlcOl1H+sZKOniJcVRMjvcGmymwmQz51KM6s?= =?us-ascii?Q?B/XTfinL4kwyWrdbCaBxsYvi1kLaiZWdbrInFxWLV0pBhDUgh7lETF9WZgFy?= =?us-ascii?Q?fjjsZ+mpf3cqKd5xXZm79kCLeVIvJ3+8C2VWbaJT6Nb52AJ765mbGmuVUfGc?= =?us-ascii?Q?6qe1zwTFUlNIBBjppMALwtymOc11o3Bhnd7Pj4OmliiKkTULgDk7TugElNdF?= =?us-ascii?Q?Y6Q1mD7LRNfCPhJNBWDdO/ffvB2HTqEoVryzeXZt4nSsMLtxsOemL5wwlb9g?= =?us-ascii?Q?hT/xj1HBVZR3TXkLXotQkxOIhpZmz5FNDXvmPdsdThybpvPqKkt8/vgm9xux?= =?us-ascii?Q?mVZX+H7l3WFHXAj390p+9Lm2ip/NUo4yMZHU3d5l4DGJjjKom2/6r/e4V1A+?= =?us-ascii?Q?Tgt/VweQnbZ+A6vh/zQgII/PDvoKMimKH1ERhyLIR64NtPaD0X1fFcNWN8lT?= =?us-ascii?Q?HerXJqnCgn1KTRaV0MuXyKXt/RMEPQkJ/v0+I/aMv2Vx3hKxg2qYIFaj34ll?= =?us-ascii?Q?9QaG+RMxVrVkf0ag8T+KWUNTo3TOjX4JaSkNDtkCYB4uNv0wnAJegQhAnXTY?= =?us-ascii?Q?Br6uXXurGJpnTH1uUhCwefh686INDLy3lkuiiihx1vxrCOvJZLcsTSueeblM?= =?us-ascii?Q?KDZj7lNnvJSb/UtJAuosXViPWguGlKenU4+R+cF4bYVCC/axf7I98GB2TsaL?= =?us-ascii?Q?Q6zROWICAUhGTCFaT8i/39RZzjJEfqvdFJ4evv6aeRTUirrMNA4QEsrEbOND?= =?us-ascii?Q?SM0bRyCUQZ9jEsyObqRFKv2b7zkyDKANz0Nbnqqy+tAp01wtcE93Bqticwyd?= =?us-ascii?Q?vylrImrrrCEmPPNJDIri36NYY7fwfgOupfbV/2i2Yt2W6kHzOJT6BweNhi3X?= =?us-ascii?Q?9IyuGJ3lIp43K/nSlXodn31ZmWQOxjq+icWSdAzgRKlswxECCRQQr4MdyEd0?= =?us-ascii?Q?MAEOuF7B5eQEfUvh02PD425qQwOglgd1OG8GMcYLqUoxcl821wArv7eZuNqs?= =?us-ascii?Q?kfYCVGXEi0CtD3nL14uPOvEhv6fxJ6mYVxN19V7+1tes7QHDDnKM+lWr64Kk?= =?us-ascii?Q?zXm08iRXWHxD0BCSZ/GokTrlzRyqxz568hgmQiWs/T+q/sXXEsIDm4bES/Hj?= =?us-ascii?Q?vi4K85QYEIN5+6kcC2MhjOMqFko2p7L7ROwCl1d5H00TRqb4qhhDVfMGMUa6?= =?us-ascii?Q?/BtcmZkCQYyxCrLlBCNtQ1LC?= x-ms-exchange-transport-forked: True 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: MW2PR12MB2492.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 27d643fd-2e35-4dbc-d121-08d8cc369bda X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2021 13:36:58.7164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wgqZTDKOcn/PlBejUpMb97Wcpt1MZiIDJFiPvbBspO2OUBfDk/WM3pqXvUldYYosgQvgaIuvI/MqIaslTXUYlw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB2478 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1612791491; bh=Wnd3ps0+Ia6SPKmnLG3hZjX2Hdrd1rQcJWll+XmijO0=; h=X-PGP-Universal:ARC-Seal:ARC-Message-Signature: ARC-Authentication-Results:From:To:CC:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs:x-header: x-ms-oob-tlc-oobclassifiers:x-ms-exchange-senderadcheck: x-microsoft-antispam:x-microsoft-antispam-message-info: x-forefront-antispam-report:x-ms-exchange-antispam-messagedata: x-ms-exchange-transport-forked:Content-Type: Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=CkKNO3/ToG0KfZlEs87QmhAkoqf3x7gHzzSFIDgCNPXfzGQT1gkSgbE4UDexyDWns wYDjl09gv3lfnHmozDV4iCdMs27ARThJKHyEmgOYpb0y22fm0FufpnnE5NoFdbSRLd lspa4nFYXNf4AxPRfXUcpKfE84dV3i7LZpg3Q9kD+MfV/xoeeo+0j+0VBz6xrK5nrT x7a5v68BmBB5kWbkdgm7SO8v98Fj2+eQLieso7l6Eu9mZnr0Wf2hhpD3iM21V1Xe+X Jj52ZhifkfKdLuDIbirWKWhmKhGpY+piv/HLUrAPgrozcks6/CjQ/eujbzuijX2xCC Zrsswe1GWetAg== Subject: Re: [dpdk-dev] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Kuztal From: Kusztal, ArkadiuszX > Hi Matan, >=20 > Few comments/questions inline with [Arek] >=20 > > -----Original Message----- > > From: dev On Behalf Of Matan Azrad > > Sent: Thursday, February 4, 2021 3:34 PM > > To: dev@dpdk.org > > Cc: akhil.goyal@nxp.com; Doherty, Declan ; > > Somalapuram Amaranath ; Ruifeng Wang > > ; Ajit Khaparde ; > > Anoob Joseph ; Zhang, Roy Fan > > ; Griffin, John ; De > > Lara Guarch, Pablo ; Michael Shamis > > ; Nagadheeraj Rottela > > ; Ankur Dwivedi ; > > Gagandeep Singh ; Jay Zhou > > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block > > sizes > > > > In cryptography, a block cipher is a deterministic algorithm operating > > on fixed- length groups of bits, called blocks. > > > > 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 function of the encryption. > > > > Some cipher algorithms support multiple block sizes, e.g. AES-XTS > > supports any block size in range [16B, 2^24B], in this case, A > > plain-text data, divided 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 pla= in-text > data. > [Arek] - Except that the last data block does not need to be n-bit long, = beside > that and lack of chaining it makes XTS no different to any other block ci= pher > mode of operation. > Block size itself for XTS-AES is always 16 bytes in the first place which= is AES > constraint. > 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is data uni= t > length that contains "data unit in bytes/ 16" AES blocks where last one c= an be > incomplete. >=20 > > > > The current cryptodev API doesn't allow the user to select a specific > > block size supported by the devices In addition, there is no > > definition how the IV is detected per block when single operation inclu= des > more than one block. >=20 > [Arek] - Do you mean tweak increment per data unit? Like one op as a data > stream (multiple data units) and tweak incremented by pmd? It can be defined differently per algorithm. I know from AES-XTS standard that the tweak should be incremented by 1 per = data-unit. So, yes, here, the driver\device should take care for the incrementation. =20 >=20 > > > > That causes applications to use single operation per block even though > > all the data is continuous in memory what reduces datapath performance. > > > > 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, > > where 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. > > > > All the new fields do not change the size of their structures. > > > > Using flags to report the supported block sizes capability allows the > > devices 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 the devices. > > > > Signed-off-by: Matan Azrad > > --- > > lib/librte_cryptodev/rte_crypto_sym.h | 12 ++++++++++++ > > lib/librte_cryptodev/rte_cryptodev.h | 23 ++++++++++++++++++++++- > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > 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 i= s 0, > > + * use the default block size provided in the capability. > > + * The value should be in the range defined by the bsf field in t= he > > + * cipher capability. >=20 > [Arek] - nowadays algorithms rather don't have different block sizes, tho= ugh I > see people set this field even for stream ciphers. > If such algorithm would happen it probably could just get a suffix in > crypto_cipher_enum. Otherwise some fixed size array could be added. First, if no different block size per algorithm, why do we need this parame= ter at all? Second, Cipher block defined to be like this D(E(b)) =3D b D: decryption function E: encryption function P: plain-text block data. In case of AES-XTS the cipher block size is the data-unit size. There is a big range of optional data, see in standard. > > + * > > + * - 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 tw= eak. > > + */ > [Arek] - if data unit would be session value (key scope in xts naming) wh= ere the > number of units would be taken from, sym_op->len ? Yes, it is already defined there that it must be multiple of block size(dat= a-unit in AES-XTS case). > (For standard storage example: data unit size -> logical block size, sym_= op->len > -> range of consecutive logical blocks.) If so it probably could be sessi= on-less op > as this cipher key would be unusable after it. >=20 Can be session and session-less modes. If the user want to operate on different groups of blocks in the same strea= m he can use the same session(key) with different ops. Am I missing here? > > }; > > > > /** 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 { }; > > > > /** > > + * 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 > [Arek] - when adding constants source should be attached as well. > > + > > +/** > > * 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 th= e > > + * 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