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 2C3DAA04B3; Sun, 15 Dec 2019 07:07:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 29FC51BFB2; Sun, 15 Dec 2019 07:07:45 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 076271BFAB for ; Sun, 15 Dec 2019 07:07:42 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBF67LsM031625; Sat, 14 Dec 2019 22:07:41 -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=d28emu0YK7h5ZwXf1txFUa908UOmXI18eVyEslw9sw8=; b=LRbSvOPECwl1aTN80LgY0Q1zEyRMnnjSEbXXFAf392lEuT4w92Q0mx1CHg0XrRd9WOS8 RDpOeaheghkKCPL+8Jbm/67zWqYiQhOE5IzlGKurNUBs4RNi63ObKROf8wrMUiZsWJip 08xFbNMYgC7TvYErpCGi80Yia1MUaCTWiXfLVgky8wX6/raDZy5Fmi+i/jEn2mE5Yq61 JS8bEr2DBfyGlpNMd5pkH9cbmhpSRrRyjGwL+Rv0gGcU7Qeu1SnEUVU6xZq7tOfHvyG4 x1cNBSZ/yPqOfWMlNKmQKwwVVW6kmxGFhV4/x/R91h4h0YlXpm/JYQ6QGiCqgUk1JoM+ Bw== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2ww04thwkh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 14 Dec 2019 22:07:41 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 14 Dec 2019 22:07:39 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.103) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sat, 14 Dec 2019 22:07:39 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h5gh7LYSClnjhaXwU1xrUoz+jJOjZgOw41+pJYk5hIdox9Z5CE4+IT0YUI4mZwncftx309/5algQY45Tk3ZYIkDC2Qhf2Yr7vxt942auNj/f3TPS7epEqG+WMtZnARXW2nA2kzyu9YtlUP6n9H+JDlcrbQ/8igTGF1VYiRWRUgK0OUFWkTvzBf88t2jgI5xCOxTpB3roIGufdvDL0zg/rgfTqhiAjRBEFEE6TMfWxrmO17v9cd/WG0QTQhUeC3hZzvolHRPNmOBuCHT6N3mkEB74KwfFbUpXbTMKBxoU+NisPiKB4GCnsOwjcf2Vygo6WxZkn/LI+jTPkfuNjQANrQ== 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=d28emu0YK7h5ZwXf1txFUa908UOmXI18eVyEslw9sw8=; b=ENlHxul/cbSuANkFWgKgFgq4N6pu79+dCWVn1xtrAdlDGk0KbztzHZWFJsgFZ2p0p2JZLIdpMg2MkaNSv6MijoMXJnvaOy0wbfVm0iUiA/+SFGxQVJ++mlFXovGHxxkbGXS1jVa0JbgbuOxHcPPbo6Fq6LwoiwwSH/wiiyk9q5V87QD5q5LAgYfXrqu8wQMK4bqqWszrv8HoeQBV/KKj6CQIXy4ZG73HxY6sWKw+4eq8ZHcdIYPyRf2hcdOhj/nxz6rQi5pBR7FIuyswSes+w7qXSwv87HDEntjv0+RlwhEbrABivmMKMGIaz6dWvc5aca4HPRu9u4xTge9YQkSvzQ== 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=d28emu0YK7h5ZwXf1txFUa908UOmXI18eVyEslw9sw8=; b=FPBkBAvEpxQKWuvvPw33FSWKeVbg8r+hhmbdCK/5CYN0BLlkoh6Si2U7sgizt1SrZOLGiIO9IVja64jTcHIBp6ApoXpWNrGSmqR6NOh7k/3DWCT8RBxKxci87aqoVr4sREMC1Lwk64hBU5tqUw3K3NEhs9cQuWorMWNhWnDDHm0= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3327.namprd18.prod.outlook.com (10.255.236.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Sun, 15 Dec 2019 06:07:37 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::358a:10f1:5e8e:f6f]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::358a:10f1:5e8e:f6f%7]) with mapi id 15.20.2538.019; Sun, 15 Dec 2019 06:07:37 +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: AQHVrpMvw4Myz8aLekOSWFJnfZYPsaexyb8AgAL/DQCAAFP3wIAC3nsAgALCnpA= Date: Sun, 15 Dec 2019 06:07:35 +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: [43.254.163.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 31d6af8c-1e28-4965-d9c8-08d7812515bc x-ms-traffictypediagnostic: MN2PR18MB3327: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(366004)(396003)(39850400004)(189003)(199004)(13464003)(8936002)(66556008)(66476007)(64756008)(2906002)(5660300002)(66946007)(66446008)(76116006)(4326008)(86362001)(15650500001)(6506007)(81156014)(8676002)(52536014)(53546011)(81166006)(7696005)(55016002)(9686003)(7416002)(316002)(71200400001)(110136005)(54906003)(186003)(478600001)(33656002)(26005)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3327; 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: gO392OZzwbjXuDbzr4jeCkXgZL60Wi5a5YOl9U+mz7g/JNcE03SnOCk/QgzJGMAa+jj7cPWUNw0e+lRGW7jL/dxyMCtJc/TlTBNyP0bMvPM8ung+Cno7xXXYIe1v1yqdSSnQYWn2XxquCDRpUkAETtu3GexD4ocjz441QhLK89a06CaqVM8HBBpIoGGc9FlC2aByHYg7CYx1e7hQI2cUOB+xw9BI6Kz00NpKBnEjiSiyufJS62w30BoSlza+ZDgElZCwfDJEgeWZf3Od7WlGAccujaohZoruodNzst9Xd9erPTsRXEA7nEWE9jrPFV3RNVlCH1SrZMvsXO5GASob+IW7bsdF85TuhrVHv6Htod8RbUTry8pUtknODGRVLa+mvg0jo7ltSpxwMMecyVOTis5er0BfR6GG1OB2LKkWoJDucSXhnDTEiItR9Mi3D+YArzQJ2XrWHjAC4FnTiUZ3sQVmgupxLRctyTedDtbcXPumVS9JnIr0vCLJNiiQgF5YMASWKSwoFwPc/7TPufnHBA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 31d6af8c-1e28-4965-d9c8-08d7812515bc X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2019 06:07:37.1107 (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: b1nvqHK+UbmBr0YJRungTQonhX9M451LVUyLOwhIHCrBvdhFKDZg4R2JpZlVPqUYyA7OBgGojyOiujocEvjz3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3327 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-14_07:2019-12-13,2019-12-14 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: Friday, December 13, 2019 5:25 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 > ---------------------------------------------------------------------- > > > > > > 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. > > > > > > > > > > Wonder what will be the usage model for it? > > > > > AFAIK, RFC 4301 clearly states that either SPI value alone or > > > > > in conjunction 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 'rte_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 enabled on one security session (ie on SA) > > > > > > > > The above rule would uniquely identify packets for an SA. But with > > > > the above usage, we would quickly exhaust entries available in h/w > > > > lookup tables (which are limited on our hardware). But if h/w can > > > > use SPI field to index > > > into 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 session. Please do note that, SPI is not ignored during > > > > the actual > > > lookup. Just that it is not used while creating 'rte_flow'. > > > > > > And this table will be prepopulated by user and pointer to it will > > > be somehow passed via rte_flow API? > > > If yes, then what would be the mechanism? > > > > [Anoob] I'm not sure what exactly you meant by user. But may be I'll ex= plain > how it's done in OCTEONTX2 PMD. > > > > The application would create security_session for every SA. SPI etc wou= ld be > available to PMD (in conf) when the session is created. > > Now the PMD would populate SA related params in a specific location > > that h/w would access. This memory is allocated during device configure= and > h/w would have the pointer after the initialization is done. > > > > PMD uses SPI as index to write into specific locations(during session > > create) and h/w would use it when it sees an ESP packet eligible for > > SECURITY (in receive path, per packet). As long as session creation cou= ld > populate at memory locations that h/w would look at, this scheme would wo= rk. >=20 > Thanks for explanation, few more questions: > Ok, so the table will be allocated at device init() somehow (nothing to d= o with > rte_flow). [Anoob] Yes. =20 > Then PMD will be able to write/update entries in that table and HW will b= e able > to read (to get SPI, keys, etc), correct? [Anoob] Yes. =20 > Now if upper layer (ipsec-secgw for example) would like to create new ESP > session on that device, what it would need to do? > Would it still need to use rte_flow API for that? > Or just call rte_security_session_create() and PMD will take update this = HW/SW > table for it? [Anoob] rte_security_session_create() is enough. =20 >=20 > > > > > > > > > > > > > The usage of one 'rte_flow' for multiple SAs is not mandatory. It > > > > is only required 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 the PMD. > > > > > > > > > > > > > > > > > > > > > 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 s= ession. > > > > > > + * > > > > > > + * 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