From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [RFC PATCH 0/1] IPSec Inline and look aside crypto
	offload
Date: Tue, 29 Aug 2017 16:49:07 +0200
Message-ID: <2166799.Q9jkndJmdM@xps>
References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com>
 <20170725112153.29699-1-akhil.goyal@nxp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, borisp@mellanox.com, declan.doherty@intel.com,
 radu.nicolau@intel.com, aviadye@mellanox.com, sandeep.malik@nxp.com,
 hemant.agrawal@nxp.com, pablo.de.lara.guarch@intel.com
To: Akhil Goyal <akhil.goyal@nxp.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id C3D6411D4
 for <dev@dpdk.org>; Tue, 29 Aug 2017 16:49:09 +0200 (CEST)
In-Reply-To: <20170725112153.29699-1-akhil.goyal@nxp.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi,

I try to understand how things are connected,
but too many things are not clear for someone not involved in security.

25/07/2017 13:21, Akhil Goyal:
> struct rte_security_session *
> rte_security_session_create(struct rte_mempool *mempool);

What is the usage of this mempool?

[...]
> These are very similar to what Declan proposed with a few additions.
> This can be updated further for other security protocols like MACSec and DTLS

You should avoid referencing another proposal without
- link to the proposal
- summary of the proposal

[...]
> Now, after the application configures the session using above APIs, it needs to
> attach the  session with the crypto_op in case the session is configured for
> crypto look aside protocol offload. For IPSec inline/ full protocol offload
> using NIC, the mbuf ol_flags can be set as per the RFC suggested by Boris.

Again a missing reference (link + summary).

Even worst, the RFCv2 references this v1 without copying the explanations.
It is too hard to track, or maybe it is cryptic on purpose ;)

[...]
> Now the application(ipsec-secgw) have 4 paths to decide for the data path.
> 1. Non-protocol offload (currently implemented)
> 2. IPSec inline(only crypto operations using NIC)
> 3. full protocol offload(crypto operations along with all the IPsec header
>    and trailer processing using NIC)
> 4. look aside protocol offload(single-pass encryption and authentication with
>    additional levels of protocol processing offload using crypto device)

I feel these 4 paths are the most important to discuss.
Unfortunately there are not enough detailed.
Please explain the purpose and implementation of each one.

> The application can decide using the below action types
> enum rte_security_session_action_type {
>         RTE_SECURITY_SESS_ETH_INLINE_CRYPTO,
>         /**< Crypto operations are performed by Network interface */

In this mode, the ethdev port does the same thing as a crypto port?

>         RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD,
>         /**< Crypto operations with protocol support are performed
>          * by Network/ethernet device.
>          */
>         RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD,
>         /**< Crypto operations with protocol support are performed
>          * by Crypto device.
>          */

I guess the difference between ETH_PROTO_OFFLOAD and CRYPTO_PROTO_OFFLOAD
is that we must re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?

>         RTE_SECURITY_SESS_NONE
> 	/**< Non protocol offload. Application need to manage everything */
> };

What RTE_SECURITY_SESS_NONE does? It is said to be implemented above.