From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id C5F461C00 for ; Wed, 10 May 2017 19:21:58 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP; 10 May 2017 10:21:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,320,1491289200"; d="scan'208";a="259539989" Received: from dwdohert-mobl1.ger.corp.intel.com (HELO [163.33.228.212]) ([163.33.228.212]) by fmsmga004.fm.intel.com with ESMTP; 10 May 2017 10:21:56 -0700 To: Boris Pismenny , radu.nicolau@intel.com, dev@dpdk.org References: <1494341879-18718-1-git-send-email-radu.nicolau@intel.com> From: Declan Doherty Message-ID: <871defdd-9388-4251-92ea-c74a4d8c4938@intel.com> Date: Wed, 10 May 2017 18:21:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC][PATCH 0/5] cryptodev: Adding support for inline crypto processing of IPsec flows 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: Wed, 10 May 2017 17:21:59 -0000 On 10/05/2017 5:07 PM, Boris Pismenny wrote: > > >> 5. The addition of inline crypto metadata into the rte_mbuf structure to allow the required egress metadata to be given to the NIC PMD to build the necessary transmit descriptors in tx_burst processing when the PKT_TX_IPSEC_INLINE_CRYPTO is set. We are looking for feedback on a better approach to handling the passing of this metadata to the NIC as it is understood that different hardware accelerators which support this offload may have different requirements for metadata depending on implementation and other capabilities in the device. One possibility we have consider is that the last 16 bytes of mbuf is reserved for device specific metadata, which layout is flexible depending on the hardware being used. >> >> struct rte_mbuf { >> ... >> /** Inline IPSec metadata*/ >> struct { >> uint16_t sa_idx; /**< SA index */ >> uint8_t pad_len; /**< Padding length */ >> uint8_t enc; >> } inline_ipsec; >> } __rte_cache_aligned; > > Assuming that you see the packet with PKT_TX_IPSEC_INLINE_CRYPTO, could you infer these parameters from the packet itself? > In our case this isn't really possible as each packet in a burst could be be associated with a different security association/crypto session and will also have different lengths/padding etc. We could use some sort of cookie to store this, but I think it would have a big performance impact. I do think that this structure in the mbuf should not be device specific as it is now for the required metadata, but I would like to guarantee that the metadata is in the mbuf. >> >> .... > > This is a nice approach. > > We are also working on adding support for IPsec inline crypto in DPDK. > I hope we could submit a RFC with working code soon. Iis your device capable of full IPsec protocol processing, ESP header insertion, encap/decap etc? In our case the inline functionality is limited to the crypto processing, so we are working on the assumption that the user will be integrating with an existing IPsec stack. On ingress the lookup is based on the Destination IP and SPI, on egress the metadata is > > We considered 3 approaches for IPsec inline support: > 1. IPsec inline as a cryptodev (like this RFC) > 2. IPsec inline as a rte_flow action. (see details below) > 3. Mix between approach 2 and approach 3. > > In approach 2, there is no need for an additional crypto PMD. > Inline IPsec is exposed as another feature of a NIC PMD. > > For the control-path, we introduce a new rte_flow_action_type for crypto > and a flag to mark flows as egress flows. > Then, it is possible to program the SA by calling rte_flow_create with > an appropriate pattern of IP and ESP header fields, and an action that > contains rte_crypto_ipsec_xform as the configuration. > > The main benefit of using the rte_flow API is that we can reuse, the > existing API with patterns and actions. For example, it would be > possible to add support for UDP encapsulation of IPsec without > changing the API. Support for VLAN/VXLAN/GRE/etc could be added > similarly to UDP encapsulation. This make sense when hw is capable of full offload. So the rte_flow actions might be VxLAN and ESP Tunnel for a flow. The other approach is that to separate rules are created one for IPsec, then a second for the VxLAN tunnel which trigger on the IPsec flow, but this probably implies that either the PMD flattens these flow actions into a single action or the hw supports re circulation. One concern I would have is population of the namespace of rte_flow with IPsec/crypto session material, but I guess it should be possible to come up with a clean way of supporting this. > For the data-path, all is handled in the NIC PMD, during rx/tx_burst. > While, the application marks the packets for encryption in the > transmit path. And it receives packets marked as decrypted/auth-fail > on the receive side. when you say the application marks the packet, this is essentially the IPsec stack? The main benefit in the approach of this RFC is that it is possible to integrate the inline crypto processing transparently in the data path. The crypto PMD can handle setting and interpreting the metadata required and the IPsec stack is just using the crypto PMD as it would any other crypto PMD. > > In approach 3, there is a crypto PMD for configuring the keys, then > the rte_flow_action_type configuration contains the crypto session > and the data-path could go through the crypto PMD as in approach 1. >