From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id B6D7C7CA3 for ; Mon, 10 Jul 2017 09:35:23 +0200 (CEST) Received: from Internal Mail-Server by MTLPINE1 (envelope-from borisp@mellanox.com) with ESMTPS (AES256-SHA encrypted); 10 Jul 2017 10:35:19 +0300 Received: from gen-l-vrt-098.mtl.labs.mlnx (gen-l-vrt-098.mtl.labs.mlnx [10.137.170.1]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id v6A7ZJVU030940; Mon, 10 Jul 2017 10:35:19 +0300 From: Boris Pismenny To: dev@dpdk.org Cc: aviadye@mellanox.com, borisp@mellanox.com Date: Mon, 10 Jul 2017 10:35:10 +0300 Message-Id: <1499672117-56728-1-git-send-email-borisp@mellanox.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [RFC 0/7] ipsec inline 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: , X-List-Received-Date: Mon, 10 Jul 2017 07:35:24 -0000 In this RFC we introduce a infrastructure for IPSec inline hardware offloading. This RFC introduces device capabilities, configuration API and data path processing. We also provide a comparison with a previous RFC posted on the list for this feature. 1. Inline crypto processing 1.1. Device Capabilities: o DEV_RX_OFFLOAD_IPSEC_CRYPTO - device support inline ipsec decryption offload. o DEV_TX_OFFLOAD_IPSEC_CRYPTO_HW_TRAILER - device support inline ipsec encrypted offload, ipsec trailer is added by hardware. o DEV_TX_OFFLOAD_IPSEC_CRYPTO_TSO - device support inline ipsec encrypted offload within segment large packets, ipsec trailer is added by hardware to each segment. 1.2. Configuration API: We will modify steering API in order to add IPsec transform actions. o Definition of ESP header: struct esp_hdr { int32_t spi; /**< Security Parameters Index */ uint32_t seq; /**< packet sequence number */ } __attribute__((__packed__)); o New flow item: enum rte_flow_item_type { ... /** * Matches a ESP header. * * See struct rte_flow_item_esp. */ RTE_FLOW_ITEM_TYPE_ESP, }; struct rte_flow_item_esp { struct esp_hdr hdr; /**< ESP header definition. */ }; struct rte_flow_item_esp { static const struct rte_flow_item_esp rte_flow_item_esp_mask = { .hdr = { .spi = 0xffffffff, }, }; o New ipsec transform: struct rte_crypto_ipsec_xform { enum rte_crypto_cipher_operation op; enum rte_crypto_cipher_algorithm algo; struct { uint8_t *data; /**< pointer to key data */ size_t length; /**< key length in bytes */ } key; uint32_t salt; /* salt for this security association */ }; /** Crypto transformation types */ enum rte_crypto_sym_xform_type { ... RTE_CRYPTO_SYM_XFORM_CIPHER, /**< Cipher xform */ RTE_CRYPTO_SYM_XFORM_IPSEC, /**< IPsec xform */ }; struct rte_crypto_sym_xform { ... struct rte_crypto_ipsec_xform ipsec; /**< IPsec xform */ }; o New flow action: enum rte_flow_action_type { ... /** * Encrypts or decrypts packets matching this flow. Must be either egress * or ingress, but not both. * * See struct rte_flow_action_crypto. */ RTE_FLOW_ACTION_TYPE_CRYPTO, }; struct rte_flow_action_crypto { struct rte_crypto_sym_xform xform; /* applied crypto transform */ }; Configuration Path | +--------|--------+ | Add/Remove | | IPsec SA | <------ Build crypto flow action of ipsec transform | | | |--------|--------| | +--------V--------+ | Flow API | +--------|--------+ | +--------V--------+ | | | NIC PMD | <------ Add/Remove SA to/from hw context | | +--------|--------+ | +--------|--------+ | HW ACCELERATED | | NIC | | | +--------|--------+ o Add/Delete SA flow: To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP using the SA selectors and the rte_crypto_ipsec_xform as the rte_flow_action. Note that any rte_flow_items may be empty, which means it is not checked. In its most basic form, IPsec flow specification is as follows: +-------+ +----------+ +--------+ +-----+ | Eth | -> | IP4/6 | -> | ESP | -> | END | +-------+ +----------+ +--------+ +-----+ However, the API can represent, IPsec crypto offload with any encapsulation: +-------+ +--------+ +-----+ | Eth | -> ... -> | ESP | -> | END | +-------+ +--------+ +-----+ 1.3. Data Path Processing: 1.3.1. mbuf Changes o New rx mbuf offload flags to indicate that a packet has gone through inline crypto processing on to the NIC PMD and the result of this processing. On failure, packets should be dropped. /** * Mask of bits used to determine the status of RX IPsec crypto. * - PKT_RX_IPSEC_CRYPTO_UNKNOWN : no information about the RX IPsec crypto * - PKT_RX_IPSEC_CRYPTO » : decryption and authentication were performed * - PKT_RX_IPSEC_CRYPTO_FAILED : ipsec processing failed */ #define PKT_RX_IPSEC_CRYPTO_UNKNOWN 0 #define PKT_RX_IPSEC_CRYPTO (1ULL << 18) #define PKT_RX_IPSEC_CRYPTO_FAILED (1ULL << 19) o New tx mbuf offload flags to indicate that a packet requires IPsec inline crypto processing and trailer construction on the NIC PMD. /** * Offload the IPsec encryption with software provided trailer. * This flag must be set by the application to enable this * offload feature for a packet to be transmitted. */ #define PKT_TX_IPSEC_CRYPTO (1ULL << 42) /** * Offload the IPsec encryption and trailer construction. This flag must * be set by the application to enable this offload feature for a packet * to be transmitted. */ #define PKT_TX_IPSEC_CRYPTO_HW_TRAILER (1ULL << 43) Egress Data Path | +--------|--------+ | egress IPsec | | | | | +------V------+ | | | SABD lookup | | | +------|------+ | | +------V------+ | | | Tunnel | | <------ Add tunnel header to packet | +------|------+ | | +------V------+ | | | ESP | | <------ Add ESP header without trailer to packet | | | | <------ Mark packet to be offloaded, add trailer meta-data | +------|------+ | to mbuf +--------V--------+ | +--------V--------+ | L2 Stack | +--------|--------+ | +--------V--------+ | | | NIC PMD | <------ Set hw context for inline crypto offload | | +--------|--------+ | +--------|--------+ | HW ACCELERATED | <------ Packet Encryption/Decryption and | NIC | Authentication happens inline | | +--------|--------+ 2. IPsec Gateway Sample Application 2.1. Add/Delete SA SAs are configured as previously via the configuration file, the user could specify which SAs require inline offload by adding "offload" for that SA. We then store for each SA whether it is offloaded in the ipsec_sa structure. Additionally, we extended the ipsec_sa structure with additional fields related to rte_flow, which are initialized if offload is requested. struct ipsec_sa { ... #define MAX_RTE_FLOW_PATTERN (4) // ETH + IP + ESP + END union { struct rte_flow_item_ipv4 ipv4; struct rte_flow_item_ipv6 ipv6; } ip_spec; struct rte_flow_item_esp esp_spec; struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN]; #define MAX_RTE_FLOW_ACTIONS (3) struct rte_flow_action_crypto crypto_action; struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS]; struct rte_flow *flow; ... int offload; #define OFFLOAD_ENABLED 1 #define OFFLOAD_DISABLED 0 ... }; When a user attempts to crete a session it checks whether inline offload is needed. If yes, then rte_flow_create is called with the parameters initialized above. In any case, create_session_cryptodev is called. The cryptodev session is used to handle software fallback for packets that are not processed by hardware. 3. Comparison with previous RFC In the section we compare the previous RFC (http://dpdk.org/ml/archives/dev/2017-May/065513.html) with this RFC. The main difference is in NIC capabilities. Mellanox hardware is capable of applying IPsec inline based on packet pattern, while intel use mbuf metadata. This API allows application to save cycles by not storing metadata on each packet mbuf, but instead store metadata once per flow. Another difference is the use of Crypto PMD for inline IPsec vs. NIC PMD. Using the NIC PMD has several advantages. First, configuration is simpler - crypto is performed by the same device to which packets are routed, and there is no chance for configuring a crypto context on one device and routing packets to another device and transmitting plaintext as a result. Second, Crypto PMD semantics imply that data has been processed after dequeue. This is not true for inline IPsec, where data is processed only when it goes through the NIC. Finally, using the NIC PMD directly has better performance, because the Crypto PMD code is not involved. Aviad Yehezkel (2): mbuf: Added next_esp_proto field example/ipsec_gw: Support SA offload in datapath Boris Pismenny (5): ethdev: add device ipsec encrypt/decrypt capability flags ethdev: Add ESP header to generic flow steering ethdev: add rte flow action for crypto cryptodev: add ipsec xform mbuf: Add IPsec crypto flags examples/ipsec-secgw/esp.c | 68 ++++++++++++---- examples/ipsec-secgw/esp.h | 13 +--- examples/ipsec-secgw/ipsec.c | 142 +++++++++++++++++++++++++++++----- examples/ipsec-secgw/ipsec.h | 30 +++++++ examples/ipsec-secgw/sa.c | 120 ++++++++++++++++++++++++---- lib/Makefile | 1 + lib/librte_cryptodev/rte_crypto_sym.h | 42 +++++++++- lib/librte_ether/rte_ethdev.h | 4 + lib/librte_ether/rte_flow.h | 50 ++++++++++++ lib/librte_mbuf/rte_mbuf.c | 16 ++++ lib/librte_mbuf/rte_mbuf.h | 38 ++++++++- lib/librte_net/Makefile | 2 +- 12 files changed, 466 insertions(+), 60 deletions(-) -- 1.8.3.1