From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 71A53292D for ; Tue, 16 May 2017 23:46:44 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1424A20861; Tue, 16 May 2017 17:46:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 16 May 2017 17:46:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=dKQP/hqFOUN5tex bHAAmN0UP/qpPnMw3t39aVzJ3RaY=; b=lVHjHVR/JhR7oyvXP+2xcA9tRgxA0G9 tkPStMszHVoAj4uLqB184hVDGKezRx4cRA1nFvy/+/+7AKhOEaIGdNWRmuZqvQJ+ e9Rxz4Ujt1R56aKj99YTaCtgRP8AB116QlN1V4JdGoqjmEKZ5BrZGqdeEgpBI2Ut J58+twQ0Fxk4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=dKQP/hqFOUN5texbHAAmN0UP/qpPnMw3t39aVzJ3RaY=; b=NERwmZjq kegHs0aI0oryeYaLjcKArWHUElzYIR9wfTT8gtnlfjkNVj85FzPe31rX5qvWJOSc nD2EYfjX9M1X4fAiHfKolXKVH1hgmwwxosD8vSJXsqJe8YmCrG5uRJ1U0dMCxEQI 5gzJlGtKC5Z/+ERkORqrdVKy4FXA1Ls9XiZqQVcXOym3VEOEwj/beWh3Fy/UuO8S kY5yFY/MnIlL5MWj86TKYKlGVuzEpO73D5Dm6UOGZbHwduckoTzk+COiYY9Ku9XX XJ9ucd8Rw3xYUTBbmCcmvAqwfj5ijwCqgkVHpnN1pRfepHuveYIqtX/gjz2PFQrM RZdviU6gN1H6Jg== X-ME-Sender: X-Sasl-enc: toydcXTiBsfQWFnvgLeq0iPopjIr57L9UVytID4ZSoKI 1494971203 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 89E6424997; Tue, 16 May 2017 17:46:43 -0400 (EDT) From: Thomas Monjalon To: Radu Nicolau Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com, declan.doherty@intel.com, Boris Pismenny Date: Tue, 16 May 2017 23:46:42 +0200 Message-ID: <4071892.busQYGyi5c@xps> In-Reply-To: <1494341879-18718-1-git-send-email-radu.nicolau@intel.com> References: <1494341879-18718-1-git-send-email-radu.nicolau@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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: Tue, 16 May 2017 21:46:44 -0000 09/05/2017 16:57, Radu Nicolau: > In this RFC we introduce a mechanism to support inline hardware > acceleration of symmetric crypto processing of IPsec flows > on Ethernet adapters within the cryptodev framework, > specifically this RFC includes the initial enablement work > for the Intel=AE 82599 10 GbE Controller (IXGBE). We must stop after this first introduction and think about what inline crypto processing is. At the beginning are two types of processing: =2D networking Rx/Tx =2D crypto Then we want to combine them in the same device. We could also try to combine more processing: =2D compression =2D pattern matching =2D etc We will also probably have in future some devices able to combine processing or do them separately (inline crypto or simple crypto). Is there a good way to specify these combinations? I'm dreaming of a pipeline model with a JIT compiler... Here we are adding one more layer to the combination of Rx/Tx + crypto: it is a specific API for IPsec. One more thing in this landscape: How the eventdev model propose to combine such processing? [...] > 3. The definition of new tx/rx mbuf offload flags to indicate that a pack= et requires inline crypto processing on to the NIC PMD on transmit and to i= ndicate that a packet has been processed by the inline crypto hardware on i= ngress. >=20 > /** > * Inline IPSec Rx processed packet > */ > #define PKT_RX_IPSEC_INLINE_CRYPTO (1ULL << 17) >=20 > /** > * Inline IPSec Rx packet authentication failed > */ > #define PKT_RX_IPSEC_INLINE_CRYPTO_AUTH_FAILED (1ULL << 18) >=20 > /** > * Inline IPSec Tx process packet > */ > #define PKT_TX_IPSEC_INLINE_CRYPTO (1ULL << 43) We won't be able to add an offload flag for every protocols. Can we define a more generic flag for Rx crypto failure? The type of Rx crypto can be defined as a packet type. IPsec is exactly the same thing as VLAN to this regard. Olivier, what do you plan for VLAN flags and packet types? Where is the item 4? :) > 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 d= ifferent hardware accelerators which support this offload may have differen= t requirements for metadata depending on implementation and other capabilit= ies in the device. One possibility we have consider is that the last 16 byt= es of mbuf is reserved for device specific metadata, which layout is flexib= le depending on the hardware being used. >=20 > 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; I really think we should stop adding such things in the mbuf. It is convenient for performance, but have we looked at other options? We cannot reserve a metadata block and share it with other layers, because it would prevent us from combining offloads of different layers. And we won't have enough space for every layers. There was the same discussion when introducing cryptodev. And the conclusion was to not directly link any crypto metadata to the mbuf.