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 2FB91A0547; Mon, 8 Feb 2021 13:10:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A7B9940693; Mon, 8 Feb 2021 13:10:32 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id A6FD04014E for ; Mon, 8 Feb 2021 13:10:30 +0100 (CET) IronPort-SDR: WFedt3cNXZBUgEyMkaCOUjig6R/b/1qoWzE/fHiK/WPH2Fd+y52lGN9ZAPGt8LxzU5MXgu2fv1 6y8eQIrqa0vg== X-IronPort-AV: E=McAfee;i="6000,8403,9888"; a="243199926" X-IronPort-AV: E=Sophos;i="5.81,161,1610438400"; d="scan'208";a="243199926" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2021 04:10:27 -0800 IronPort-SDR: k9BCqs8u6M3q+cdzJhXr8K7QyAMvYSBnNyO054XS7bmMMkkxuMLLhWFM4uXw9AiS4g551XRVcW cEIeDY5i0/ZA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,161,1610438400"; d="scan'208";a="358763407" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga003.jf.intel.com with ESMTP; 08 Feb 2021 04:10:26 -0800 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 8 Feb 2021 04:10:25 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Mon, 8 Feb 2021 04:10:24 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 8 Feb 2021 04:10:24 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HjkHJ+xuLnWUzj/km8FZYdPY6L5qI6zDB09jjDoiyAnN27kbG17+eDLKXfHYlybcONTd5t+Ck5K/HcUMWKXBjzTr/VmktoC8f8hB3CTtKBDEt8s+2s2hmZLHWI3zVEqCB5XmGtpyVnRBn85ZQRQMEIwQ7UjvuufU04KvGfHWT5cyCAup+R8SmbyMl9MZV8NAFtjHgKLzFCgdBaWg9iA8irvALFTnVDSBTe9S4dGZD7txZANdpdvnc5yu/TQQYchgOjkyiyArYRmqkLAEZstjh6+n2LGqHascg47CC78Y5HOa4pKHYmWuhMO6I/3TgD8xsp0foBoEoNyyuMb7rxOitA== 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=Db0/Xs29U7k8t0aJUnuHasjNW+7cfQ1FozcetLuUDyw=; b=GfEkzKhlO+1hQnwV8AvUTfE7EohjXV2HtmGn8e2XPYXXAyVMebnVK01La/wsmkgNoT3dnlZWKlIqYA8q88CxlsVuL1OQn++j4045VhSxBT9a2bRCUq5F1oiVoSBB/Bt4Pos+fQnhDCZW/e5+OLVbbzPPbjqgT5DzfXChHJTynUyv8rfrBMC59ZxDASrOoYyABT0bRqrcU1ujLNIU2Tcq+dzjoH+Q4md+O0VJ8UTPPstOChF/3OOtq62LgRkdvjAsCr63z0phyWLc8zxfcFkxqz2F6Vnh+QtB8Mts+myzwoNrEQXlet5ZlJIm/CtZ3Qy8jxD0BpdTUBY6snf4RT96Lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Db0/Xs29U7k8t0aJUnuHasjNW+7cfQ1FozcetLuUDyw=; b=fJPUoJH1WKhuHlap7+vnihtP90KxxSbpAzi7jXeeShTp17gRF2bE8m3mneHnX9cwnKipvGOuzBHyXQEnQn7Z5HlOE0wtSHByrGN1OkIV1LNVDjnOJcQz6rJrGprA4Q/TfzfewTTcbd4jqKSlkcola13VfOttyKxQ/MEVT1WrvEc= Received: from CY4PR11MB1830.namprd11.prod.outlook.com (2603:10b6:903:125::21) by CY4PR1101MB2104.namprd11.prod.outlook.com (2603:10b6:910:1b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17; Mon, 8 Feb 2021 12:10:20 +0000 Received: from CY4PR11MB1830.namprd11.prod.outlook.com ([fe80::918d:fda8:f181:1af0]) by CY4PR11MB1830.namprd11.prod.outlook.com ([fe80::918d:fda8:f181:1af0%3]) with mapi id 15.20.3825.030; Mon, 8 Feb 2021 12:10:20 +0000 From: "Kusztal, ArkadiuszX" To: Matan Azrad , "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+wL0hikMeVRrxE2cpoYyRSs5mKpOCI/w Date: Mon, 8 Feb 2021 12:10:20 +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-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.151.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7df5ad15-a0de-4719-761e-08d8cc2a8154 x-ms-traffictypediagnostic: CY4PR1101MB2104: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr 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: y9esm/WfYZ+VdjUDbgfrEwsg8QdcnlAhsSv6TECgSp7C/rQc6gztn6mkEOk/Sk3KdKOlqvIu6AYWgDp1v9hcgL4Mk81r+bUW1l92il4tIFEHSt6OFHRmY/cXTkMQuEBLOqbxQ3TIpeNBDXHrUIoKSadFF/MEsXoOlWYIUwDXdmaeAaCYYjV+TGBakMqz0jNgygmuz+TiQXcaJCv5qtocNYYTQpKYoL2+huNAGQJtoRQVqAkZTqrP1FZzWTpjaYZYcTX0LPYVg0b8sB6IM4RfGDp6ipBuxnClARRRDYfaullp7FKZJW4/UW+rQkgXpcg2qMfnJkvvQ0ZU79UppL4Z8E18lM6PI142cqu1t3M+t8UTYGu4ON7WQ0+OYQ3R0H5Vd+NDvB/PJgRi36AH/BTXCeazCD2o69zYvgm3M4xUw70FcWliOhh79ofO7HQF8Mmf4E2PWJiDeFZIJ5uI7I4At98TTsQmKXYpIECruMzcL8/4aCTXeJZxzpdZ/4boCAd0lBwFvAkiCxwaAGnGPCrTpg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR11MB1830.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(39860400002)(346002)(396003)(136003)(55016002)(7696005)(53546011)(6506007)(478600001)(9686003)(5660300002)(8676002)(71200400001)(33656002)(86362001)(52536014)(64756008)(7416002)(66446008)(26005)(66556008)(66476007)(76116006)(66946007)(2906002)(8936002)(316002)(110136005)(186003)(54906003)(83380400001)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?0eAXs1aaXJd8iu6nJean/WnU+QPYkGNVhxu2mCU4ZUHgxmkeXXNscGSHbryW?= =?us-ascii?Q?LRan2Z1OTRXe3UFtPnXkQEDDho3z2HtybOF8Iz7JZO/QvQNVAYWePM/BVZSV?= =?us-ascii?Q?ywOTjn6j+lG5HtKCN3Q1HoWERb+D4pyewDE/P8cCiSM2UMEW/mjvek9hH0iI?= =?us-ascii?Q?vGJOCvtMGlt8slZYNeNAGJlukJyJ2jvu5FYcB3nTiIJlxFe90J2wQGQ585oY?= =?us-ascii?Q?/6JC0KWuijpAjTBQ67Bh/HPYvZur1xUY7aKW18lKjOdQrW5sQaXErMNbmngt?= =?us-ascii?Q?Z+nITzfHRua/JBuguQfvnahDvLwepou0QKaDq8T4raW8oKqayPB3NCKNjtWw?= =?us-ascii?Q?Xpz63SZyD+QxgYZX1vJFxuFqhHaHNCcHG3/RyhSAkLGCR+LsiA+wROYdQNfg?= =?us-ascii?Q?PeG6KHmRd7dtwKl+AQREB5JihhHwpZdW+GNPpgUkFzd59Oo/eyXhvj/JFzf9?= =?us-ascii?Q?vbSp0RQNY/L3nPUrwkr404FXEp5vcTT0dsNYB0UvMnZTroimEDLpXnyQkdT0?= =?us-ascii?Q?3vilRIPGyOhmvXXoPpTfNn/NO5kwitV7Mbg1XNjg0MwpZJSO3kvd4xTUxY2Z?= =?us-ascii?Q?4LWHPTVPr71ARFlyN5tvKvGRKeUVXAurMkVbw+mGvHX3cdbM1hoYGOXFlJlm?= =?us-ascii?Q?GTs48X+cpjeIH1gy08YKOIpcMIUO9PNqCIKbbzpS9vtr0mY2mrpaWmggMoxr?= =?us-ascii?Q?VUWxyvctU+JRVHnViFK1QKtJUmg7Hufr6nEB8SBvDKIytzwZK/kZ7zhunXAv?= =?us-ascii?Q?PO5i9ZrPCF9lA2to4xt+NhB6/UTHwDO3AA2AEX/wx5XDOTKC1hy5OfTNVD0+?= =?us-ascii?Q?9VWuQ/3Lw4Lxo/IQwMWxvLWv+shi/ewjo2c0fkP/jghMyJbj7xtGXvTpdwiX?= =?us-ascii?Q?Cane8FQfzmbhMTJKlcoxXYGiZI8v2fxuPTRX5WBCCxDBbV/e3oP0AASX2n11?= =?us-ascii?Q?7oWQgd6gqpBbYU6vG2asfNiX5woLbNUtoTGfPIB1olZ3CjWSnU8u0+nm4kuv?= =?us-ascii?Q?2tCOgfR+HSMctBWygloQRMgMnbYqutKi2roM/h77GgizAVibL2S3ajRcW/fU?= =?us-ascii?Q?fVXIoMkVktinBpiorgheU14TXiEySJhCJMe4Jw8jDWnnIeCXvliI3HZ/9n2O?= =?us-ascii?Q?Ats/xH6qOl0B6M01rIg1do7NXiKQGNaWoQbVrq4kgOPQKofUw6O3nbBHX+vo?= =?us-ascii?Q?RuGZ6tWuQUwpnvKuxTlYrRpedDwR7f3VWcV9ft0pMWamJWHMSCyNEVqmeEkm?= =?us-ascii?Q?Juq3d+Shy//SOsgeDzaSL8izcPcLebYh8RHdoioAeuvsJybmc/PpLBWkkT1i?= =?us-ascii?Q?Icopn8Fpk4pZ1aYqCSwDKp2z?= 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: CY4PR11MB1830.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7df5ad15-a0de-4719-761e-08d8cc2a8154 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2021 12:10:20.1654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xXk7rtwRKblcMEchM7DNcwKbKSlpVKRwbdpFDgwgcQ+lLWG7hRRWn8ORpmD+rfLIjCuqNIaWxU78ZMiAuXZriuHjdhwwoxC3Aky6wukSvqc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2104 X-OriginatorOrg: intel.com 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 Matan, Few comments/questions inline with [Arek] > -----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 Lar= a > Guarch, Pablo ; Michael Shamis > ; Nagadheeraj Rottela > ; Ankur Dwivedi ; > Gagandeep Singh ; Jay Zhou > Subject: [dpdk-dev] [PATCH] cryptodev: support multiple cipher block size= s >=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 function 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, divide= d 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 or= der to > get the same plain-text data. [Arek] - Except that the last data block does not need to be n-bit long, be= side that and lack of chaining it makes XTS no different to any other block= cipher mode of operation. Block size itself for XTS-AES is always 16 bytes in the first place which i= s AES constraint. 2^20 * 16B -> 2^24B constraint from IEEE 1619-2017, SP800-38E is data unit = length that contains "data unit in bytes/ 16" AES blocks where last one can= be incomplete. >=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 i= s > detected per block when single operation includes more than one block. [Arek] - Do you mean tweak increment per data unit? Like one op as a data s= tream (multiple data units) and tweak incremented by pmd? >=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. [Arek] - nowadays algorithms rather don't have different block sizes, thoug= h I see people set this field even for stream ciphers. If such algorithm would happen it probably could just get a suffix in crypt= o_cipher_enum. Otherwise some fixed size array could be added. > + * > + * - 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. > + */ [Arek] - if data unit would be session value (key scope in xts naming) wher= e the number of units would be taken from, sym_op->len ? (For standard storage example: data unit size -> logical block size, sym_op= ->len -> range of consecutive logical blocks.) If so it probably could be session-less op as this cipher key would be unus= able after it. > }; >=20 > /** Symmetric Authentication / Hash Algorithms diff --git > a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptod= ev.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 [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 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