From patchwork Fri Oct 6 13:06:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Power, Ciara" X-Patchwork-Id: 132360 X-Patchwork-Delegate: gakhil@marvell.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4FCB6426D0; Fri, 6 Oct 2023 15:06:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DC068402C8; Fri, 6 Oct 2023 15:06:33 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 5E298400D7 for ; Fri, 6 Oct 2023 15:06:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696597592; x=1728133592; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=JcGukeP0nCSoTjnNW33A1kJXKDVN5zRpTdRCcyI60WA=; b=S/pf9JWxsO/W8SMeTe9Mx6gj6vIC4nv4orYZ7WijYxsQ12+QKuWRj/pn tzU72dyCcWXkEJ/Xm7v44rV5FfGgpg+1nLeUZUdrC3o7ebQpSkxYCX9XK 9TmI3CLOIUjBZf7NJa2SjCy2pY33sxVkGvqyPaQUKYHRDRUghxzxTmPt/ zVPu/15gwuthK9MO5H1DqgNluwskTYM/+7UfuGvptrlTXPwqh/xjyyPWZ jAerooZtB5CnB6IyCO1gJf5ghUIH/SkgQSWAZSiCKwg2vfKlEA62QghzD tG+MTs0CByVryjPA+c+NkstTzyKIrO5g552zslsaTy4tW7tv2f/++fb2S Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10855"; a="383636799" X-IronPort-AV: E=Sophos;i="6.03,204,1694761200"; d="scan'208";a="383636799" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Oct 2023 06:06:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10855"; a="1083441739" X-IronPort-AV: E=Sophos;i="6.03,204,1694761200"; d="scan'208";a="1083441739" Received: from silpixa00400355.ir.intel.com (HELO silpixa00400355.ger.corp.intel.com) ([10.237.222.80]) by fmsmga005.fm.intel.com with ESMTP; 06 Oct 2023 06:06:29 -0700 From: Ciara Power To: dev@dpdk.org Cc: kai.ji@intel.com, Arkadiusz Kusztal , Ciara Power , Akhil Goyal , Fan Zhang Subject: [PATCH v1] cryptodev: clarify usage of the block ciphers Date: Fri, 6 Oct 2023 13:06:21 +0000 Message-Id: <20231006130621.694334-1-ciara.power@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230811174155.2550338-1-arkadiuszx.kusztal@intel.co> References: <20230811174155.2550338-1-arkadiuszx.kusztal@intel.co> MIME-Version: 1.0 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 From: Arkadiusz Kusztal Some of the API comments incorrectly limited the usage of symmetric crypto fields to block ciphers. Signed-off-by: Arkadiusz Kusztal Signed-off-by: Ciara Power Acked-by: Kai Ji > --- lib/cryptodev/rte_crypto_sym.h | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h index 5be0f05397..53b18b9412 100644 --- a/lib/cryptodev/rte_crypto_sym.h +++ b/lib/cryptodev/rte_crypto_sym.h @@ -279,7 +279,7 @@ struct rte_crypto_cipher_xform { * * - For block ciphers in CTR mode, this is the length * of the counter (which must be the same as the block - * length of the cipher). + * length of the cipher) or a 12-byte nonce (AES only) * * - For CCM mode, this is the length of the nonce, * which can be in the range 7 to 13 inclusive. @@ -643,7 +643,7 @@ struct rte_crypto_sym_op { uint32_t length; /**< The message length, in bytes, of the source buffer * on which the cryptographic operation will be - * computed. This must be a multiple of the block size + * computed. */ } data; /**< Data offsets and length for AEAD */ struct { @@ -685,22 +685,12 @@ struct rte_crypto_sym_op { * and the length encoding in the first two bytes of the * second block. * - * - the array should be big enough to hold the above - * fields, plus any padding to round this up to the - * nearest multiple of the block size (16 bytes). - * Padding will be added by the implementation. - * * - Note that PMDs may modify the memory reserved * (first 18 bytes and the final padding). * * Finally, for GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), the * caller should setup this field as follows: * - * - the AAD is written in starting at byte 0 - * - the array must be big enough to hold the AAD, plus - * any space to round this up to the nearest multiple - * of the block size (16 bytes). - * */ rte_iova_t phys_addr; /**< physical address */ } aad; @@ -731,8 +721,9 @@ struct rte_crypto_sym_op { * source buffer on which the cryptographic * operation will be computed. * This is also the same as the result length. - * This must be a multiple of the block size - * or a multiple of data-unit length + * For block ciphers, this must be a + * multiple of the block size, + * or for the AES-XTS a multiple of the data-unit length * as described in xform. * * @note