From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 To: "Ananyev, Konstantin" , Akhil Goyal , Adrien Mazarguil , "Doherty, Declan" , "Yigit, Ferruh" , Jerin Jacob Kollanukkaran , Thomas Monjalon CC: Ankur Dwivedi , Hemant Agrawal , Matan Azrad , "Nicolau, Radu" , Shahaf Shuler , "Narayana Prasad Raju Athreya" , "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: References: <1575801683-27269-1-git-send-email-anoobj@marvell.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Konstantin, Please see inline. Thanks, Anoob > -----Original Message----- > From: Ananyev, Konstantin > Sent: Monday, December 9, 2019 6:49 PM > To: Anoob Joseph ; Akhil Goyal ; > Adrien Mazarguil ; Doherty, Declan > ; Yigit, Ferruh ; Jerin= Jacob > Kollanukkaran ; Thomas Monjalon > > Cc: Ankur Dwivedi ; Hemant Agrawal > ; Matan Azrad ; Nicolau, > Radu ; Shahaf Shuler ; > Narayana Prasad Raju Athreya ; 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 > > --- > > 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