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 18396A04F1;
Mon, 9 Dec 2019 14:57:21 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 5B45F2BAB;
Mon, 9 Dec 2019 14:57:20 +0100 (CET)
Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com
[67.231.148.174]) by dpdk.org (Postfix) with ESMTP id EA9AD1F5
for <dev@dpdk.org>; Mon, 9 Dec 2019 14:57:18 +0100 (CET)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1])
by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id
xB9DtQF7025469; Mon, 9 Dec 2019 05:57:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com;
h=from : to : cc :
subject : date : message-id : references : in-reply-to : content-type :
content-transfer-encoding : mime-version; s=pfpt0818;
bh=AM8KUNxFnBoZo0Q10qKJkNcPJWyZ4dcnuj3tuq/jXEw=;
b=b0aAs32Gko+QUeoE81cvw08BCevDAE1rmUNGGWwVHqyl55OrFl+OLAzrpjr3OQfnDGfK
Tspak/x3IKkxJ2jwhcSQ5QZjujFzgNx2E5f2xR5g8id4evnnvHdoc6pizgz8cs3Fa5P7
LupfBaCa10/nVaG0yUbyJAVj8cmBAXDo/rg93iXBf0adyv0PfxysyiCR1lIs7R/PoV31
04Ue3hG11bH91qeNIWYoSBvSD04RCoFFjIIyn50XecH/BaWtgzl8BfVkxPeUf/CMi8im
KnU6F/TtuCT+BmB+zSsSQDFWgx1tJm6EZcM6D331O5n7fr67VaSErNJ9J0CsagaE5BoE GQ==
Received: from sc-exch04.marvell.com ([199.233.58.184])
by mx0a-0016f401.pphosted.com with ESMTP id 2wrbawp0at-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT);
Mon, 09 Dec 2019 05:57:17 -0800
Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH04.marvell.com
(10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 9 Dec
2019 05:57:15 -0800
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.50) by
SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server
(TLS) id
15.0.1367.3 via Frontend Transport; Mon, 9 Dec 2019 05:57:15 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=kq27MvzH6YLHQXgz1QV5WSdjgtyXnhJdOikzbbon+x887FDITvVekeZ4ugRiKjw4vv06YOfZutdyUT9LoMmeYLswr7ecQdXQEoDIThXa94BDW/LBQPCgxXhqyXQ/FOBguZuyevnt6Dz4mA8PfnvfD4aw3ILj7Sc8GIYk8/DfwjwF88Iaj/1pvfIzTBKIgt4kkTswmZM5L2lrkJhSXS/904of1yb2h2EcD6kJUNSzSi8FLYgCkTtVFNdVwJKIaO4o/4KKEt3EZRhu9GFFCO55gWJrTTWC5vXigIEAMzQbkT0TDx4lMoqOoXV+tzILoUCEWpm3fenwvHqH/77jmnNk/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=AM8KUNxFnBoZo0Q10qKJkNcPJWyZ4dcnuj3tuq/jXEw=;
b=N5YzpmILVW9buk5h/uPFER76XM4dYKCq9yePidkYK0kVbRcOu4dJEEEjSMLsI1w9g+p28VdLb61kGBoJUDJgUv2uh56dIKuNq7Les/+CmFHODsm/onBpwdAS6Zx4v/eWED2zEudpQ4iTsOf8G5gTlwGtWgLPy41QYYm5LBM5fFI5NhqNa9QzxmjGT+kiOXF7OWwvOcS+MOUSapDoxbGuY5a0zB9iL65oMuWahwJiiW8HJX3ZhgUcmzegRO54LvqkxWoJkC8Ex3q/kFqFp11TQ4gM41Qg20DzCd7tgqLUfy2YnEB4KS5MiGIPTRh8Hv0m7tu7SLkBZJE5QIUpVbfwMQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com;
dkim=pass header.d=marvell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=AM8KUNxFnBoZo0Q10qKJkNcPJWyZ4dcnuj3tuq/jXEw=;
b=lBhEx+sEvk3jYgkTNzb6/LUXoL1Sb9d+ZxkbD+1THNwIojigwwfKqfAr0XzpuBduuFvxx50hXrZGxWwvw9f3dbf9M5dzcc2512Y+IQkwEgR+bbVq5cX5gJDxOgLlFPcH0qXXEjV7Q69yCTbVL9nvuFM0FGDSjg3IzesxxTzC1FQ=
Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by
MN2PR18MB2687.namprd18.prod.outlook.com (20.179.84.77) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2516.18; Mon, 9 Dec 2019 13:57:14 +0000
Received: from MN2PR18MB2877.namprd18.prod.outlook.com
([fe80::984b:6198:b374:9117]) by MN2PR18MB2877.namprd18.prod.outlook.com
([fe80::984b:6198:b374:9117%7]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019
13:57:14 +0000
From: Anoob Joseph <anoobj@marvell.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Akhil Goyal
<akhil.goyal@nxp.com>, Adrien Mazarguil <adrien.mazarguil@6wind.com>,
"Doherty, Declan" <declan.doherty@intel.com>, "Yigit, Ferruh"
<ferruh.yigit@intel.com>, Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
Thomas Monjalon <thomas@monjalon.net>
CC: Ankur Dwivedi <adwivedi@marvell.com>, Hemant Agrawal
<hemant.agrawal@nxp.com>, Matan Azrad <matan@mellanox.com>, "Nicolau, Radu"
<radu.nicolau@intel.com>, Shahaf Shuler <shahafs@mellanox.com>, "Narayana
Prasad Raju Athreya" <pathreya@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH] ethdev: allow multiple security sessions to use one rte
flow
Thread-Index: AQHVrpMvw4Myz8aLekOSWFJnfZYPsaexyb8A
Date: Mon, 9 Dec 2019 13:57:14 +0000
Message-ID: <MN2PR18MB2877B0C35B11432B9FA02452DF580@MN2PR18MB2877.namprd18.prod.outlook.com>
References: <1575801683-27269-1-git-send-email-anoobj@marvell.com>
<BN7PR11MB25478BD0152762D4CB1E16FC9A580@BN7PR11MB2547.namprd11.prod.outlook.com>
In-Reply-To: <BN7PR11MB25478BD0152762D4CB1E16FC9A580@BN7PR11MB2547.namprd11.prod.outlook.com>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [111.125.192.33]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9c45dd02-bb94-46cb-e796-08d77cafb1fe
x-ms-traffictypediagnostic: MN2PR18MB2687:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR18MB2687CD037CA9819EF50F1F62DF580@MN2PR18MB2687.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 02462830BE
x-forefront-antispam-report: SFV:NSPM;
SFS:(10009020)(4636009)(346002)(366004)(39860400002)(396003)(136003)(376002)(189003)(13464003)(199004)(9686003)(478600001)(55016002)(66556008)(66946007)(7696005)(66476007)(229853002)(76116006)(64756008)(66446008)(71190400001)(186003)(71200400001)(4326008)(33656002)(54906003)(7416002)(86362001)(110136005)(52536014)(316002)(15650500001)(5660300002)(305945005)(8676002)(81156014)(81166006)(26005)(6506007)(55236004)(53546011)(8936002)(2906002)(921003)(1121003);
DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2687;
H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en;
PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: marvell.com does not designate
permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Tc8v/QgMDlIRV5q+M6a3iRViXnZqIWDs14/Tgclsv8hE1XBxbZ0xoKXXVv+QCk/icYCZ9dQntxmaPVBsjii8O2iS0x3C4b2bNZHNqgBU2ZBAJLkfynsOCz2/78vZdFdv/RAxYOIQoayJSAQkK9FeJyKGN1pNoVy0ciI/0vJB83KLKcni1d23jYssz3pK994OHqNJV+6n9/qU2KQHPpPnmpJr6P5TRjM7WyiJEkDmHZ5C8NA/vj+pYzUY1cyDAoeJpux4dLSHL8p+3nORm5hNQzGWfV+rZHGTlv5rZFdJ8XB9tq7Cpmw22sSyjWpum5BRRzLFg6iblJvdzsyjvvNXx6mHkHJJJM8+HqvCQcJL8OpOWP+ggwLIo/or6l9MyE9ly0XxkgjdRkhlL3Z4Th4IGrxVDhGpGhnhKs2xigNIgBiHuy/CXGEu3sDib6rSf+Y6k4DI5zagi2vxfpK4qj/w64XTQ5rfZ/h/iB9XHIzLfTX4hoVq689FrdOXnrE7LaIE78RbjP0FaXje1SX3ur3vow==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9c45dd02-bb94-46cb-e796-08d77cafb1fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 13:57:14.2139 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ynCDOx9pe7edGOStQo9GEkAQ0y4m6A3KeK3DO5ZZBcUWb5299w6tg8dls45kKvAFdKrjiCu4IouTlUFwIT4jtA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2687
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572
definitions=2019-12-09_04:2019-12-09,2019-12-09 signatures=0
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>
Hi Konstantin,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Monday, December 9, 2019 6:49 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <akhil.goyal@nxp.com>;
> Adrien Mazarguil <adrien.mazarguil@6wind.com>; Doherty, Declan
> <declan.doherty@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>; Jerin=
Jacob
> Kollanukkaran <jerinj@marvell.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: Ankur Dwivedi <adwivedi@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Matan Azrad <matan@mellanox.com>; Nicolau,
> Radu <radu.nicolau@intel.com>; Shahaf Shuler <shahafs@mellanox.com>;
> Narayana Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org
> Subject: [EXT] RE: [PATCH] ethdev: allow multiple security sessions to us=
e one
> rte flow
>=20
> External Email
>=20
> ----------------------------------------------------------------------
>=20
> >
> > 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.
>=20
> Wonder what will be the usage model for it?
> AFAIK, RFC 4301 clearly states that either SPI value alone or in conjunc=
tion with
> dst (and src) IP should clearly identify SA for inbound SAD lookup.
> Am I missing something obvious here?
[Anoob] Existing SECURITY action type requires application to create an 'rt=
e_flow' per SA, which is not really required if h/w can use SPI to uniquely=
identify the security session/SA.
Existing rte_flow usage: IP (dst,src) + ESP + SPI -> security processing en=
abled on one security session (ie on SA)
The above rule would uniquely identify packets for an SA. But with the abov=
e usage, we would quickly exhaust entries available in h/w lookup tables (w=
hich are limited on our hardware). But if h/w can use SPI field to index in=
to a table (for example), then the above requirement of one rte_flow per SA=
is not required.
Proposed rte_flow usage: IP (any) + ESP + SPI (any) -> security processing =
enabled on all ESP packets
Now h/w could use SPI to index into a pre-populated table to get security s=
ession. Please do note that, SPI is not ignored during the actual lookup. J=
ust that it is not used while creating 'rte_flow'.
The usage of one 'rte_flow' for multiple SAs is not mandatory. It is only r=
equired when application requires large number of SAs. The proposed change =
is to allow more efficient usage of h/w resources where it's permitted by t=
he PMD.
>=20
> >
> > 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>
> > ---
> > 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