From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 71A53292D
for <dev@dpdk.org>; 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: <xms:Q3MbWSSYoUmXVwDxi32p32VBM7YPF2rVTJEVGMZQC5qngg26AO9Xgg>
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 <thomas@monjalon.net>
To: Radu Nicolau <radu.nicolau@intel.com>
Cc: dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com,
declan.doherty@intel.com, Boris Pismenny <borisp@mellanox.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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.