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 5EAE5A055D; Mon, 1 Mar 2021 08:56:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0F85540684; Mon, 1 Mar 2021 08:56:22 +0100 (CET) Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by mails.dpdk.org (Postfix) with ESMTP id 9DA954014E for ; Mon, 1 Mar 2021 08:56:19 +0100 (CET) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Sun, 28 Feb 2021 23:56:18 -0800 Received: from HQMAIL107.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Sun, 28 Feb 2021 23:56:18 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Sun, 28 Feb 2021 23:56:18 -0800 Received: from HQMAIL109.nvidia.com (172.20.187.15) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Mar 2021 07:56:18 +0000 Received: from HQMAIL111.nvidia.com (172.20.187.18) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Mar 2021 07:55:49 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by HQMAIL111.nvidia.com (172.20.187.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 1 Mar 2021 07:55:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WBHdWQYxcfmY2vQnuQ8npdrMu7MCHFpDU17gOimOweCiEz9T3uauEMF5WtEH2FOO28XhGAlMCdgn1Yzo0HH2GwuIJXZbeV3sRH+YaCXm/r8w87TImtm99HwfDH8SmyfBio1tKQLZaaxOVIK6IhJ00vxV4P78gQGQXISVDIBKabTcpM75NJKFgOys0X4frRznSPhhMKexLmOrIjTnA6/CiGx+hmRHcDBJ8xnQ3wNH0pPqq3f+8F/eqxb0+e7cpQ6pUgYQeufwz4gu1RrNTZFVX0zth2tacm3tO9pWzlFifsefisc59U6Rxo3TzmnuU+VRdl9Fuy4ZYS2O7amLX+oXbA== 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=Y2Sc1OdTjbsJjrEnRYu9LLI4udht290ERdOGsJTpP8I=; b=D+/6E2L0aminksBk9C7NFY2RVWU024QJPszG58vBWhBeoZl12IPAsebn6hJEKg791dyiEkmM8vkWz680TumhhxHjR26eRb878nW7rJ2HDGJEdfReMF2uivklTqj4KnKjxLStBAxLQ/B6RitScyi70CIRq4lYTSCIGzMqe40CCb3jl8wfcbwiY6sLsgDGq8o+0IHvhjq9XJh5Fux7/QmdFPUdkbXT6e4FEBaG+paDGKSgPO/4KKdAQ7IkEM/MDTvSBIQyXXhbh8feAXjQn2FTWlI1LjZuXOUQ4QUFFc3F8HysLYobkFBJGBUi9IAbJX9XeWWHbFXbTYusyBuk/cNabQ== 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 MWHPR1201MB0192.namprd12.prod.outlook.com (2603:10b6:301:5a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Mon, 1 Mar 2021 07:55:47 +0000 Received: from MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::99f2:8567:2f9e:c351]) by MW2PR12MB2492.namprd12.prod.outlook.com ([fe80::99f2:8567:2f9e:c351%4]) with mapi id 15.20.3890.028; Mon, 1 Mar 2021 07:55:47 +0000 From: Matan Azrad To: Anoob Joseph , "dev@dpdk.org" CC: Declan Doherty , Somalapuram Amaranath , Ruifeng Wang , Ajit Khaparde , Fan Zhang , "John Griffin" , Pablo de Lara , Michael Shamis , Nagadheeraj Rottela , Ankur Dwivedi , Gagandeep Singh , Jay Zhou , Akhil Goyal , "Jerin Jacob Kollanukkaran" Thread-Topic: [EXT] [PATCH] cryptodev: support multiple cipher block sizes Thread-Index: AQHW+wLiyZS95CeI4k+/3gG8QlAt1qpqAsuAgAThS0A= Date: Mon, 1 Mar 2021 07:55:47 +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: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [109.67.16.141] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f69e34f6-d48e-4171-6431-08d8dc876ce8 x-ms-traffictypediagnostic: MWHPR1201MB0192: 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: rRYtMg7mdmAjWngfNCwugZseJopp53iY0oY8ZyhD2JqWCZcKDCTnVY42VQ1En5PEy8xF7PsHy6e+v7KWGV0mUl4/O8gZOkRyV4QOWMvf8ZE/wFHG+MWMN+Rs2cvt/vrCHMcfUqCR/kE/XwhE331Bm3ARKOMrK03kSbQilIzaOYFRqigzyE419/6xwYv540eBwmPYXo7GoAnaOpzXIH81hrg6jGcjy04jEakC5YztPtISkVXx3Ud1YwZfwewFwDD88p2xqCN691VKc3m3rdR7gAqwTv7f+d1G3ctBBiQ4B9s2mi5qHxdDnt1vFx09GQrC++BenoeSf709ZduwPpnKqB+6xUyVtzibjz394dvhUypoFnO/5nHmctHhBWpttRz2zM8Ads6azhOwUNffoDMhAHWXQLZjHR1vBph/KHYkJjbYfnSk630QOW1h1jOIfRLJw0MHxMK0ucu4kE1M5yL09x6NDzeSEAeukCw+zv/iecS5oFCglIjm4FSiCrvzx+RKqfKFXer5Am35rEPEDBBB2A== 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)(366004)(39860400002)(376002)(136003)(396003)(346002)(71200400001)(7696005)(53546011)(5660300002)(6506007)(4326008)(33656002)(83380400001)(478600001)(8936002)(8676002)(7416002)(316002)(66946007)(54906003)(86362001)(52536014)(110136005)(64756008)(66446008)(9686003)(66556008)(76116006)(66476007)(55016002)(186003)(26005)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?OkMbDHM5mn+/fCUN32PCgYQ3ik7+R+3++e/IX+rkSWvR3aIUZnGkAjz7fU4z?= =?us-ascii?Q?lZOfnux9vBcM4C0reF6b03Nb1gLkYnXWrNrgSeKgLBGTSIEUzLc8W4hc5Mcv?= =?us-ascii?Q?ooNyus8hPVW8dsOJQSD0JmCurTL4FZyTrla0fvcDvdCRAvEzRM8svkpDLjJz?= =?us-ascii?Q?4WfmwagNHO3RVwzgFPky6LOGTLBizLNYK6WVCyG1+ATR2E3uQQWDWA0/5Vp2?= =?us-ascii?Q?1upSkwEj4lKY+EfgUlLd+swRHd82yIxKx4V5026g1VWARDMNz82TrkD2p4+w?= =?us-ascii?Q?6Hq5uDvqZTyzcgBLrQTJxoLibEqOY80cGxyG/5SDXHher+mjZtjWmcNQh6G2?= =?us-ascii?Q?bWm0nDo+3iKOfF6c3GEf1tWF2eG0MJHQocv+j0rl6KUEAL2H+BOgdaeb2vH9?= =?us-ascii?Q?1pIQQ4d8mcpRsbke5jQ3GEuQcqtixa7JoLzLDK7RDKaR2FQ6LCCVaHMf/ooC?= =?us-ascii?Q?asdWbEoU2bnQ5Q0qBQdTOUtRNSrM+NwRtZRr8k0wyb/WiGCGo/fblz29mL3F?= =?us-ascii?Q?Bu9IRlyQwKlw5SBVjQ2+V0S1/AHqeYn0+tdNuXm1LqRiPI6SR7AORuUklWW3?= =?us-ascii?Q?zQ4hQc7oALanTgGTgaESoui01DYneq5uESwqZMGiZQyho0mUQorYBOErDKfF?= =?us-ascii?Q?HR+MKMd9bKQmKG0uIbtPQOH/fy24HXVcCi/MJM4Qdb/UkGHdwaiTeLTdVgI8?= =?us-ascii?Q?Rlh5hvTy/pOwOZO5/UGv/Sdc0WZXM8L+YWrZm8aeVMQFT8umD29DuWJbMaCg?= =?us-ascii?Q?7elcaLsjfkZvFvjYKtePWdNaQpUwhLbqbsIWgEbc/a+mvFjlF7x7e9f50PWZ?= =?us-ascii?Q?jvbq/xYgM3aLYjgCzSOl2GbXkhc8xwGiMJxLOtVpnBsiuqEJq1t4esr3x8eN?= =?us-ascii?Q?84f/+2A76sFJ6inswphwiPfGuti5rokf9rS6cFTXHNPCVNePixawnZkM4imo?= =?us-ascii?Q?yHrtyLICcOmhSbI/8bkQ3bUGsLaUDui9ivPQuILZY253JyN9I3EZ+5B3CPAA?= =?us-ascii?Q?9PnVTP+b0WzO/ppjDymI+EXmDidc3DupSeKnbciuoSGK6nryIMzKmjrw1NN5?= =?us-ascii?Q?4hFQcfgvVb9IQNebBsXJ/G+FeR+Sbq84ecUc3FM30TtWliS0XOut8ewXAGK4?= =?us-ascii?Q?lZBDVGfbbZzjFdKk1NphJvHAXuR4vyHOSmSLFE8lv2YvU0W1SxiMQRM3vfTU?= =?us-ascii?Q?yeVpoeeSmweABAmF3jNSwZNIyamtuIAHC/JUINwLWvBIkz8WgHEk/tyBl+Gx?= =?us-ascii?Q?ajPsJMHGW6rH9lm7XcHS0wS1QnHMcme0dyxGy/wL/Z8dFBsJc1C6NOTs4XLm?= =?us-ascii?Q?qz6HXklAcfxkQWIajLQJuMyt?= 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: f69e34f6-d48e-4171-6431-08d8dc876ce8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2021 07:55:47.7101 (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: 1I3RRpoguFIW4HFoPnnAk+Qe9PMyk9unXsPAz9cQFCNl+5gExdIQBRnHYkHdO43DMYsJl0En4FVR7H21AhQHNA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0192 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1614585378; bh=Y2Sc1OdTjbsJjrEnRYu9LLI4udht290ERdOGsJTpP8I=; 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=faeblp0TGm1g7JWc0795I5ZrF6S1CqZQ3ljBhTfjcCvwawhk5kv7IyrEQrQcgsLoT a3xbn7J1j5S1YmbhUB6moVhVn1Xbmz6+4wd8kstr5EGw3idI8qNQrZE9XCMx6veUuw vUSEXPuz6EkJgTxJBdA5evG/fNgyYaqB6DzolkKPF3n8Rksenn155Zp4mND1LvU3EI 49wdWOtA3d8V5xMxVNDRP9GcMsGaHB0E7dYNr1hAaLsLhHEPhJnsOWG9MbxvS1HxV/ uDSb4UlGU1lCuG+HxCOq+aICUgfaiGlEydWtE7v63ev3zAXBpMhiIaDxTh3XHgLeCP 2vCLqmNWRkNMw== 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Anoob Joseph > Hi Matan, >=20 > With the current spec, AES-XTS operation offloading would mean applicatio= n is > expected to track data blocks and the corresponding tweak & cipher steali= ng, > while the final crypto operation gets offloaded to PMD. This proposal aim= s at > moving the entire AES-XTS operation (including tweak update) to PMD. Did = I > understand the proposal right? Yes, we want to define well what is the "data-unit" size from AES-XTS stand= ard per session (or operation), then, to allow to the PMD users to send mul= tiple data-units in one operation. The initial tweak(for the first data-unit) will be set by the user in the o= peration, and according the standard(probably what you call "spec") the res= t data-units tweak values should be assigned consecutively, so this part w= ill be done by the PMD\device in multiple data-units case.=20 >=20 > If yes, I believe this is a good feature to be added. But I've few questi= ons, >=20 > 1. Who is responsible for cipher stealing? Do we expect PMD to pad the fi= nal > data unit? Sure, this is the offload, no? to support what the algorithm defines. > 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-X= TS is > used in disk encryption where selected pages are updated without requirin= g the > entire disk to be decrypted (& encrypted after). Did you consider if we c= ould > 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). Sure, For any amount of consecutive data-units, the user can do encrypt\decrypt i= n one operation: 1, 2, all the disk..... in one mbuf or chain of mbufs... But the blob of data must be multiple of the session data-unit size paramet= er that I want to define now in the session API(\ transformation). > 3. On top level, this requirement has similarities to rte_security. Did y= ou > consider that route? No, but why do you care? The regular crypto API should support it too, it i= s basic... > Thanks, > Anoob Thank you. =20 > > -----Original Message----- > > From: Matan Azrad > > Sent: Thursday, February 4, 2021 8:04 PM > > To: dev@dpdk.org > > Cc: akhil.goyal@nxp.com; Declan Doherty ; > > Somalapuram Amaranath ; Ruifeng Wang > > ; Ajit Khaparde ; > > Anoob Joseph ; Fan Zhang > > ; John Griffin ; > > Pablo de Lara ; Michael Shamis > > ; Nagadheeraj Rottela > > ; Ankur Dwivedi ; > > Gagandeep Singh ; Jay Zhou > > Subject: [EXT] [PATCH] cryptodev: support multiple cipher block sizes > > > > External Email > > > > ---------------------------------------------------------------------- > > 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. > > > > 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. > > > > 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. > > + * > > + * - 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. > > + */ > > }; > > > > /** 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 > > + > > +/** > > * 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