From patchwork Fri Aug 11 17:41:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arkadiusz Kusztal X-Patchwork-Id: 130188 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 AE65843036; Fri, 11 Aug 2023 19:42:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9F14E40E03; Fri, 11 Aug 2023 19:42:00 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id E4ABE40144 for ; Fri, 11 Aug 2023 19:41:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691775720; x=1723311720; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=jbFLzYH0r09AEfy3mpX9m3yNBOfn4pHTjNDZAjLl5AE=; b=hNwSutz0fxBquEOU0ekHoexxXLnfwN7B/yDNYKDZG0xFJO4/tHbE5pXP huAGFg/t2UZj4OU8sb0aL88I8q0udYOEChO+gBznhWIjAzY871mbnXnkY GzHNzp6FiuuPgDPnFlmyiAQ0oxCgzk9sxEvK0wiPL2kBl/D9syp78iZ/k t0g14ijNQ4Hbjm3/P1co0GKoKWcpwtAev08ExKL8K56fZd5GHzxJyYQHc ypBKeK2R59eQB1ln6nVGe5v3GP8Nn6Q3P4WHKKLFMZXtO8+/jOBHf0ouv yTAFOCNG+ko4IBXDOg3os02WmdAQN5w3A+wwGeRZ8uuenytXURp0xc68B Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10799"; a="375439658" X-IronPort-AV: E=Sophos;i="6.01,166,1684825200"; d="scan'208";a="375439658" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2023 10:41:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.01,202,1684825200"; d="scan'208";a="876253564" Received: from silpixa00400465.ir.intel.com ([10.55.129.105]) by fmsmga001.fm.intel.com with ESMTP; 11 Aug 2023 10:42:00 -0700 From: Arkadiusz Kusztal To: dev@dpdk.org Cc: gakhil@marvell.com, kai.ji@intel.com, ciara.power@intel.com, Arkadiusz Kusztal Subject: [RFC] cryptodev: clarify usage of the block ciphers Date: Fri, 11 Aug 2023 17:41:55 +0000 Message-Id: <20230811174155.2550338-1-arkadiuszx.kusztal@intel.com> X-Mailer: git-send-email 2.34.1 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 Some of the API comments incorrectly limited the usage of symmetric crypto fields to block ciphers. Signed-off-by: Arkadiusz Kusztal --- lib/cryptodev/rte_crypto_sym.h | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h index 76c868c503..d1ae982b93 100644 --- a/lib/cryptodev/rte_crypto_sym.h +++ b/lib/cryptodev/rte_crypto_sym.h @@ -139,6 +139,7 @@ enum rte_crypto_cipher_algorithm { RTE_CRYPTO_CIPHER_AES_XTS, /**< AES algorithm in XTS mode */ + /* Should we not deprecate this algorithm by now?*/ RTE_CRYPTO_CIPHER_ARC4, /**< (A)RC4 cipher algorithm */ @@ -284,7 +285,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. @@ -661,7 +662,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 { @@ -703,22 +704,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; @@ -749,8 +740,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