From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 859C1A04F1;
Mon, 9 Dec 2019 08:37:28 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 590542C12;
Mon, 9 Dec 2019 08:37:28 +0100 (CET)
Received: from mail-il1-f195.google.com (mail-il1-f195.google.com
[209.85.166.195]) by dpdk.org (Postfix) with ESMTP id B7DD123D
for <dev@dpdk.org>; Mon, 9 Dec 2019 08:37:26 +0100 (CET)
Received: by mail-il1-f195.google.com with SMTP id u16so11845361ilg.10
for <dev@dpdk.org>; Sun, 08 Dec 2019 23:37:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=Cn+I9bCsrDgzAkXXWb8GwozPFgMQOyu41ineooZ/xag=;
b=kLOQUTvtaLfq26QQlFP8WCH/CBChNCPlFK9DbNnZp2zNKIjRMqf9/BxCqEr2vkmx97
oMYmAVqFtr+yTyFGD2XebvReKIHnueVLG6JSUvDD21DqxPV/DzUwmExE/SRtO+kWc3P0
JDS6ck9NYdw4xB22tUzx0fv97rS/sKuebXpVOKbY13Tp6rXkVGmBKATLuVxYx3hFnlWY
TeCdpgRo5j0Jq+j0gZWX8OIaaib/9vt192ogsp/JVIHCn+ix1hwhwZz4aL+1yp+qM3YV
qF8YZjAAplJOztNKPz3yD7OUdFb9hYnMhoIeAMTigf1GVrca5CbesFEXReJ31NNr8gmL
t77A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=Cn+I9bCsrDgzAkXXWb8GwozPFgMQOyu41ineooZ/xag=;
b=mRdMI3+p9fE6Mi6DHQV9wj3LfNpIgmctAYo4e15hCnvYQ2gsDGJhi2rPg83HhqdXhA
89x7V9GKTt9ekhK+gi3SRvI1vf6LtMDvXRk8YB33Ki0rRW7LItvP0ynQOmJGXWhdx1Uk
lJaOp+OBKhyOb68pHWL/5LqDMGB0TnfBx0+pIERAu9dlhvBj8QnVp2RZkAGmNSYxK3Ox
YJWFFgYrkxH2XJKdvVpUK5rsME/oiKNpmHkNhbI+zW4NFvCeDtvzwxRQ7toAqPtemL+H
eLAcnkhpHcXLhKtguViksyqc5H7cXdHEhTeNuoFv+y2pX1wk0uAsQetnumZpkyWbY9DC
jUng==
X-Gm-Message-State: APjAAAX7bSYHqgSzsb9nVE+bsSYkuV9rpAnH0hZuhT3iDn/lk1vnXXxi
62dUOtCZuTvkG9S+kfYKBymMbUehRDaK463Thyc=
X-Google-Smtp-Source: APXvYqxsGL1CVYbjrNB2moG8dW6dKyDB0RbxFiAlYaofbMEaMZw7sqh05amQM3FW9BBNrrqmChAhHFerFX7EU9CNtbQ=
X-Received: by 2002:a92:aa4d:: with SMTP id j74mr27370862ili.271.1575877045829;
Sun, 08 Dec 2019 23:37:25 -0800 (PST)
MIME-Version: 1.0
References: <1575801683-27269-1-git-send-email-anoobj@marvell.com>
In-Reply-To: <1575801683-27269-1-git-send-email-anoobj@marvell.com>
From: Jerin Jacob <jerinjacobk@gmail.com>
Date: Mon, 9 Dec 2019 13:07:09 +0530
Message-ID: <CALBAE1OyQJ=V253rCv5dSsyxKBkPGH+qinghDCd0A+y-db7VBw@mail.gmail.com>
To: Anoob Joseph <anoobj@marvell.com>
Cc: Akhil Goyal <akhil.goyal@nxp.com>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Declan Doherty <declan.doherty@intel.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
Jerin Jacob <jerinj@marvell.com>, Thomas Monjalon <thomas@monjalon.net>,
Ankur Dwivedi <adwivedi@marvell.com>, Hemant Agrawal <hemant.agrawal@nxp.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>,
Matan Azrad <matan@mellanox.com>,
Radu Nicolau <radu.nicolau@intel.com>, Shahaf Shuler <shahafs@mellanox.com>,
Narayana Prasad <pathreya@marvell.com>, dpdk-dev <dev@dpdk.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions to
use one rte flow
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On Sun, Dec 8, 2019 at 4:19 PM Anoob Joseph <anoobj@marvell.com> wrote:
>
> The rte_security API which enables inline protocol/crypto feature
> mandates that for every security session an rte_flow is created. This
> would internally translate to a rule in the hardware which would do
> packet classification.
>
> In rte_securty, one SA would be one security session. And if an rte_flow
> need to be created for every session, the number of SAs supported by an
> inline implementation would be limited by the number of rte_flows the
> PMD would be able to support.
>
> If the fields SPI & IP addresses are allowed to be a range, then this
> limitation can be overcome. Multiple flows will be able to use one rule
> for SECURITY processing. In this case, the security session provided as
> conf would be NULL.
>
> Application should do an rte_flow_validate() to make sure the flow is
> supported on the PMD.
>
> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
Reviewed-by: Jerin Jacob <jerinj@marvell.com>
> ---
> lib/librte_ethdev/rte_flow.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index 452d359..21fa7ed 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -2239,6 +2239,12 @@ struct rte_flow_action_meter {
> * direction.
> *
> * Multiple flows can be configured to use the same security session.
> + *
> + * The NULL value is allowed for security session. If security session is NULL,
> + * then SPI field in ESP flow item and IP addresses in flow items 'IPv4' and
> + * 'IPv6' will be allowed to be a range. The rule thus created can enable
> + * SECURITY processing on multiple flows.
> + *
> */
> struct rte_flow_action_security {
> void *security_session; /**< Pointer to security session structure. */
> --
> 2.7.4
>