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 76142A04F6; Wed, 11 Dec 2019 12:06:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BC1EA2C6A; Wed, 11 Dec 2019 12:06:08 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 5C6051D9E for ; Wed, 11 Dec 2019 12:06:06 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2019 03:06:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,301,1571727600"; d="scan'208";a="414791756" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga006.fm.intel.com with ESMTP; 11 Dec 2019 03:06:05 -0800 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 11 Dec 2019 03:06:04 -0800 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 11 Dec 2019 03:06:04 -0800 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.55) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 11 Dec 2019 03:06:04 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jW6m0I8mgj44wHm5QLccQbXxoL48rHr7XoHxJM+A34pyDi2OmyLGOPyp+8TmMxQ9ZxYxk+JIBdqwIgizD3MJVsEB452ix8+QkMax7TqAM4X+1cPYMf75gxDagCetNenOUxyawNmqz6jvQNTT1hzbXY0KER29+46zcBlLgXNdAy1j1KZuU6gDotNhsyKoThF6rOuOWPrzMGFq23t78fWJkMbbIXqQLFv59ZGpbY6RqXomp8jejO5RiaruuXn6hCxBCri8Lg6aAVcGDMEEjuaDus6TjRfFWKqo9R8ZCju8GwNmEa6UTG1YjSKqVPCdIwWWUBDsw9NHl4vHdDeky+iRMw== 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=RvUvTL9QUd93vD7P+EsXkTWGrbytkQx9XYmPbkkn9KE=; b=EtrorJWq2ITjSv3S2zNQ+7FXt/9LOyb1S4pfv2MuVZwML9kh1tP6A04wpVLHcaNYEvwKJNs6G+33642uKIboWLC4HtW7IGZkTaNNXeBGCIOj4FW9w6vWgqOm2O437MHL1Mg11WqOxJ6zOfn4SyD1PWHSVaUXz69SBfBiZbBVIFsJ5jND6EI+1IB/8lPhQ9SFhhICi0BQcHlpappAEQyqWk7qhDAIfgWcbB4FpIs4hASAGhQ0o9UUFZkbFJ8Q2fCWUnOnVoy29r20PJavCaZ3YJljFY4ytkSDGDxmo8p4hCcKneLdaYdFNXrJMnR4MV36Kvtpa38XJXFGRR7DfSQz0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RvUvTL9QUd93vD7P+EsXkTWGrbytkQx9XYmPbkkn9KE=; b=LYvjwfrTMTNAxN8XfATZMHNrcJ0mkNOnhXmExIKuOyAM4LzmYDjs9aL8kilCHf5Jqd4g3VXeBuS611H2DyrW60sjv+6E8ObQN5s1I/DNjoty0ttm2o/iYAJPzZ0AKq7coVHz5IZ7q+mWphkantpfQ4AzVYnxw9xDHRgFK34/X1c= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2529.namprd11.prod.outlook.com (52.135.245.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Wed, 11 Dec 2019 11:06:02 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2516.018; Wed, 11 Dec 2019 11:06:02 +0000 From: "Ananyev, Konstantin" 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" Thread-Topic: [PATCH] ethdev: allow multiple security sessions to use one rte flow Thread-Index: AQHVrbU6Hm2DnT5vjU6vDGoMxULIsaexx8cAgAAN7QCAAvJkUA== Date: Wed, 11 Dec 2019 11:06:02 +0000 Message-ID: References: <1575801683-27269-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDM2Y2UyZWMtYTAzMC00OGEzLWE5MjctMmVkZTJiZDhkNTZiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiS251ZVFQak5WaFp3cnpCN3k5Z3czMXBLZjZHNnZkWURXWHVXaTRPa0VXSzhXSHFBRHUrUVFBWDN3UFhoSEdaRCJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.167] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f21bff9-dca4-45e5-531c-08d77e2a1c66 x-ms-traffictypediagnostic: BN7PR11MB2529: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(189003)(199004)(15650500001)(7416002)(26005)(54906003)(9686003)(66556008)(4326008)(498600001)(7696005)(2906002)(66446008)(6506007)(55016002)(110136005)(186003)(81166006)(66946007)(64756008)(81156014)(76116006)(8676002)(5660300002)(66476007)(86362001)(8936002)(52536014)(71200400001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR11MB2529; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ajSIug3geUEilg+moIA/Z1ykpUMFCHicyCdlSkyG7oNu16QTd736KH3asH/Q+W9VQM64jh7Chqey4OOzdn+GGbBRDFd3FCPOavtnQVspkJizoet0yTyOWw96b4Zc81zaw4Q2Hw/IYUsiPnGFE91Oq9I4MG3z/UzMTubquCo1kv/ZY5Hfr4j2wuV/pd9vKWb9QB1Bq1/EDSrBLGqK1e+bQIjFREAXOjgHj86TAyiidrXdo3fQBD1jXA3M9z5F/gh9MO5KyVFrx6SxanhzaSRYsX61qQZEQe7zcFJy8CDTir77XvcfrLXtm+pmi0+F4AH6U/TLOJNaJRtFoE1IybGwVoZxgHPZcvGo7VBSQLnlXbr6jNKMMD+1vzPa/TxmrPaMWblouVfEL9DhSfH6etl1JVex+gz1+8cFlE7+p2u+UrH1+8N2bucwiD24FVHIkZNQ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9f21bff9-dca4-45e5-531c-08d77e2a1c66 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 11:06:02.3960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kMWiNOWr1hOfu750eAH4P4S/dG93rxZqn+apNnOexoKkysYJ4YXlxET7JHeEYw3X+aifvJFhXlp7Vcj92ftKpsW6oYJjuF5WyyCmZPipmyE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2529 X-OriginatorOrg: intel.com 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" > > > > > > 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 conju= nction with > > dst (and src) IP should clearly identify SA for inbound SAD lookup. > > Am I missing something obvious here? >=20 > [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. >=20 > Existing rte_flow usage: IP (dst,src) + ESP + SPI -> security processing = enabled on one security session (ie on SA) >=20 > The above rule would uniquely identify packets for an SA. But with the ab= ove 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. >=20 > Proposed rte_flow usage: IP (any) + ESP + SPI (any) -> security processin= g enabled on all ESP packets >=20 > 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 someh= ow passed via rte_flow API? If yes, then what would be the mechanism?=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 i= t's permitted by the 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