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 5964AA0562; Wed, 14 Apr 2021 21:38:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C6B80161C9E; Wed, 14 Apr 2021 21:38:37 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id A7054161C9A for ; Wed, 14 Apr 2021 21:38:35 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 13CEB5C00B6; Wed, 14 Apr 2021 15:38:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 14 Apr 2021 15:38:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= OpZRbNDbwdk7EDlYyPr2Fsxj2HmBu8CAWwk7z+wwgAM=; b=fttAMdFfQq6S8HbN p8L6tZtMHjfWrtidUwqFAs3K9QpNqbNlqmUQhRBds3i+QD2pPRFvcbLMswOkDFBg JSj/JkO64Yq9VzFUPI1XGqa8Bp44XyHGAuplLcPeT4iUvWedioWkSQ1YxiUQ8b8z aXnU2IVKJMuxDkZuV1X84ZyBBfUXUQ/w+lyc96lnrr+ynOA8t1W2jjnivyFulTp/ OT3YaM2AvzFcK5c1IMbvR+EnjQUvpFcQynjzPCIbjOX4Ca/6Je7OrSsNg9YyuVMQ XH+HHA1nWhswxam4zXOMz+PQkheOrBZ4k9S+1bKWik8FYw5+0pnsSY62W2ykyKM1 L9dcGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=OpZRbNDbwdk7EDlYyPr2Fsxj2HmBu8CAWwk7z+wwg AM=; b=pfVXPr6boJItmdyu3m20j1aCGGil/R8tLgbo6q5uk4XJmv1uFm/tvsyN1 z3xjMDoyTih0f8E7Bn61YQTJe2ECNXMyNiWFhsi3/uJyFE505I0KgU8rSYYevC4H hKz6lDqVnpPebN1GAg9AjKkDvDAX2f3eoFZq/HjQk9HOvEwxELC4xD98WoCBEMUC TCrasDw4EKHk5WmAyj/kvi6a5gU76NDHa2k+cIZVF6yNzzzfacEAtD1JdPdSQOus XVYhnHdbhWKJKM7KHLPLWDaehHJnPFftUsaJKd0Cirmo1puBZtihDpBC9HDUu2dK vHnVull4uqrsXe2AMFOQYAIwT8KbA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeluddgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 357531080064; Wed, 14 Apr 2021 15:38:33 -0400 (EDT) From: Thomas Monjalon To: Akhil Goyal Cc: "dev@dpdk.org" , "arkadiuszx.kusztal@intel.com" , Anoob Joseph , Matan Azrad , Ray Kinsella , Neil Horman , Declan Doherty Date: Wed, 14 Apr 2021 21:38:31 +0200 Message-ID: <2068151.q8ePLV6qny@thomas> In-Reply-To: References: <1612449252-395208-1-git-send-email-matan@nvidia.com> <20210413204250.3989341-1-thomas@monjalon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] [PATCH v4] cryptodev: support multiple cipher data-units 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" 14/04/2021 20:37, Akhil Goyal: > Hi Thomas, > > > + RTE_STD_C11 > > + union { /* temporary anonymous union for ABI compatibility */ > > + > > struct { > > const uint8_t *data; /**< pointer to key data */ > > uint16_t length; /**< key length in bytes */ > > @@ -222,6 +225,27 @@ struct rte_crypto_cipher_xform { > > * - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes). > > * - Both keys must have the same size. > > **/ > > + > > + RTE_STD_C11 > > + struct { /* temporary anonymous struct for ABI compatibility */ > > + const uint8_t *_key_data; /* reserved for key.data union */ > > + uint16_t _key_length; /* reserved for key.length union */ > > + /* next field can fill the padding hole */ > > + > > + uint16_t dataunit_len; > > + /**< When RTE_CRYPTODEV_FF_CIPHER_MULTIPLE_DATA_UNITS is > > enabled, > > + * this is the data-unit length of the algorithm, > > + * otherwise or when the value is 0, use the operation length. > > + * The value should be in the range defined by the dataunit_set 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 IV. > > + */ > > + > > + }; }; /* temporary struct nested in union for ABI compatibility */ > > + > Can we add a deprecation notice also in this patch to remove these temporary > Struct and union, so that we remember to remove them in 21.11 I thought about it, but a deprecation notice may involve new design considerations and requires 3 approvals. I think it is better to send it separately. > > @@ -127,6 +135,11 @@ struct rte_cryptodev_symmetric_capability { > > /**< cipher key size range */ > > struct rte_crypto_param_range iv_size; > > /**< Initialisation vector data size range */ > > + uint32_t dataunit_set; > > + /**< > > + * A bitmap for a set of the supported data-unit > > lengths. > > Add reference to the newly created macros here > > > + * 0 for any length defined in the algorithm standard. > > + */ Yes, I've seen this miss after sending. I'll reword like this: * Supported data-unit lengths: * RTE_CRYPTO_CIPHER_DATA_UNIT_LEN_* bits * or 0 for lengths defined in the algorithm standard.