From patchwork Fri Jul 3 12:39:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Coyle, David" X-Patchwork-Id: 72999 Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 03483A0519; Fri, 3 Jul 2020 15:02:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 39D7F1DB77; Fri, 3 Jul 2020 15:02:23 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id BBE821DB5B for ; Fri, 3 Jul 2020 15:02:21 +0200 (CEST) IronPort-SDR: L6tu7tJS2ylnHrDKZw0BC/v0uAoE2JQFSHv2pjzQSNKsFFPdWhQq2YtOfzElCsC7gqBNKQU90R zKTsOVhW52/Q== X-IronPort-AV: E=McAfee;i="6000,8403,9670"; a="208655540" X-IronPort-AV: E=Sophos;i="5.75,308,1589266800"; d="scan'208";a="208655540" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jul 2020 06:02:20 -0700 IronPort-SDR: zlRJE4y6C+CshIcMag+R6O5t6aRkFBidZ9bN5SDVKSgLhTngBvbo8oq6HXyUNHRUP47RqIpjqQ +VpKDAOoOo4A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,308,1589266800"; d="scan'208";a="322412663" Received: from silpixa00399912.ir.intel.com (HELO silpixa00399912.ger.corp.intel.com) ([10.237.223.64]) by orsmga007.jf.intel.com with ESMTP; 03 Jul 2020 06:02:15 -0700 From: David Coyle To: akhil.goyal@nxp.com, declan.doherty@intel.com, pablo.de.lara.guarch@intel.com, fiona.trahe@intel.com, roy.fan.zhang@intel.com, konstantin.ananyev@intel.com Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@intel.com, brendan.ryan@intel.com, hemant.agrawal@nxp.com, anoobj@marvell.com, ruifeng.wang@arm.com, lironh@marvell.com, rnagadheeraj@marvell.com, jsrikanth@marvell.com, G.Singh@nxp.com, jianjay.zhou@huawei.com, ravi1.kumar@amd.com, bruce.richardson@intel.com, olivier.matz@6wind.com, honnappa.nagarahalli@arm.com, stephen@networkplumber.org, alexr@mellanox.com, jerinj@marvell.com, David Coyle Date: Fri, 3 Jul 2020 13:39:26 +0100 Message-Id: <20200703123933.52351-1-david.coyle@intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200630163049.61900-1-david.coyle@intel.com> References: <20200630163049.61900-1-david.coyle@intel.com> Subject: [dpdk-dev] [PATCH v4 0/7] add support for DOCSIS protocol X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Introduction ============ This patchset adds support for the DOCSIS protocol to the DPDK Security API (rte_security), to be used by the AESNI-MB and QAT crypto devices to combine and accelerate Crypto and CRC functions of the DOCSIS protocol into a single operation. Performing these functions in parallel as a single operation can enable a significant performance improvement in a DPDK-based DOCSIS MAC pipeline. Background ========== A number of approaches to combine DOCSIS Crypto and CRC functions have been discussed in the DPDK community to date, namely: 1) adding a new rte_accelerator API, to provide a generic interface for combining operations of different types 2) using rawdev through a multi-function interface, again to provide a generic interface for combining operations of different types 3) adding support for DOCSIS Crypto-CRC to rte_security The third option above is the preferred approach for the following reasons: - it addresses the immediate use case to add DOCSIS Crypto-CRC support to DPDK so that it can be consumed easily by cable equipment vendors - it uses an already existing framework in DPDK - it will mean much less code churn in DOCSIS applications, which already use rte_cryptodev for encryption/decryption Use Cases ========= The primary use case for this proposal has already been mentioned, namely to add DOCSIS Crypto-CRC support to DPDK: - DOCSIS MAC: Crypto-CRC - Order: - Downstream: CRC, Encrypt - Upstream: Decrypt, CRC - Specifications: - Crypto: 128-bit and 256-bit AES-CFB encryption variant for DOCSIS as described in section 11.1 of DOCSIS 3.1 Security Specification (https://apps.cablelabs.com/specification/CM-SP-SECv3.1) - CRC: Ethernet 32-bit CRC as defined in Ethernet/[ISO/IEC 8802-3] Note that support for these chained operations is already available in the Intel IPSec Multi-Buffer library. However, other DOCSIS protocol functions could be optimized too in the future using the same rte_security API for DOCSIS (e.g. Header Checksum (HCS) calculation). v4: * addressed Akhil's comments regarding documentation * made some code fixes * fixed possible NULL pointer dereference when allocating security_ctx in AESNI-MB and QAT PMDs * freed security_ctx memory when exiting AESNI-MB and QAT PMDs * added session IOVA verification update when creating security sessions in QAT PMD v3: * removed rte_security_op definition * now using rte_crypto_sym_op->auth.data fields for CRC offset and length as suggested by feedback from Akhil and Konstantin * addressed Pablo's comments * removed support for out-of-place for DOCSIS protocol from QAT PMD * updated dpdk-crypto-perf-test tool for DOCSIS * updated documentation v2: * added rte_security and rte_cryptodev code changes * added AESNI MB crypto PMD code changes * added QAT SYM crypto PMD code changes * added crypto unit tests * added security unit tests v1: * added proposed API changes * added security capabilities to aesni_mb crypto PMD David Coyle (7): security: add support for DOCSIS protocol cryptodev: add a note regarding DOCSIS protocol support crypto/aesni_mb: add support for DOCSIS protocol crypto/qat: add support for DOCSIS protocol test/crypto: add DOCSIS security test cases test/security: add DOCSIS capability check tests app/crypto-perf: add support for DOCSIS protocol app/test-crypto-perf/cperf_ops.c | 82 +- app/test-crypto-perf/cperf_options.h | 5 +- app/test-crypto-perf/cperf_options_parsing.c | 67 +- app/test-crypto-perf/cperf_test_throughput.c | 3 +- app/test-crypto-perf/cperf_test_vectors.c | 3 +- app/test-crypto-perf/main.c | 5 +- app/test-crypto-perf/meson.build | 2 +- app/test/test_cryptodev.c | 513 ++++++ ...t_cryptodev_security_docsis_test_vectors.h | 1544 +++++++++++++++++ app/test/test_security.c | 88 + doc/guides/cryptodevs/aesni_mb.rst | 8 + doc/guides/cryptodevs/features/aesni_mb.ini | 1 + doc/guides/cryptodevs/features/qat.ini | 1 + doc/guides/cryptodevs/qat.rst | 7 + doc/guides/prog_guide/rte_security.rst | 114 +- doc/guides/rel_notes/release_20_08.rst | 21 + doc/guides/tools/cryptoperf.rst | 5 + drivers/common/qat/Makefile | 3 + .../crypto/aesni_mb/aesni_mb_pmd_private.h | 19 +- drivers/crypto/aesni_mb/meson.build | 2 +- drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 301 +++- .../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 125 ++ drivers/crypto/qat/meson.build | 2 + drivers/crypto/qat/qat_sym.c | 71 +- drivers/crypto/qat/qat_sym.h | 62 +- drivers/crypto/qat/qat_sym_capabilities.h | 42 + drivers/crypto/qat/qat_sym_pmd.c | 61 +- drivers/crypto/qat/qat_sym_pmd.h | 4 + drivers/crypto/qat/qat_sym_session.c | 153 ++ drivers/crypto/qat/qat_sym_session.h | 11 + lib/librte_cryptodev/rte_crypto_sym.h | 14 + lib/librte_security/rte_security.c | 5 + lib/librte_security/rte_security.h | 38 + 33 files changed, 3348 insertions(+), 34 deletions(-) create mode 100644 app/test/test_cryptodev_security_docsis_test_vectors.h