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 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 ; 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 To: Matan Azrad , "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+wLf0yv335b8QkWqE7I+84R4Fapp95fA Date: Fri, 26 Feb 2021 05:01:15 +0000 Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > 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 d= e > Lara ; Michael Shamis > ; Nagadheeraj Rottela > ; Ankur Dwivedi ; > Gagandeep Singh ; Jay Zhou > > 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 > --- > 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