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 C72FBA2EFC for ; Thu, 19 Sep 2019 12:53:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9AE7D1EF40; Thu, 19 Sep 2019 12:53:33 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 8484B1EF3E for ; Thu, 19 Sep 2019 12:53:32 +0200 (CEST) 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 x8JAoOYk019553; Thu, 19 Sep 2019 03:53:31 -0700 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=upbw4JBZlNWlNEGAlVneaLyzboRlkk5OhwLON/rdMbI=; b=SkZcIcsaCi0dPE3Wc1g7G8JLGybUXrJjaA3jh5o73Mu5IGTcu+CeIw2WEHKnQpkf1dQ7 gWm/BqLiIJcTrx4ub8FKBBUtHdL3jgQ3T5eL+vJXj8sYnqLtJSbZLYopBL4hjbx+c0rZ 1ycdJlKCaJKrEp9I6NQ+FMoD9kPAzOlU3bC4EllMZlOTh5DsgHgZn94+3UP3LYSNB6iX /APAJ8kWmfqj7QligiDh2YCY28TbxjesZwhxKBQLO7Qle8LalrT994hEUuLFxFJwiVK0 F7T03rSfPYzRtBW+vGw/zIV8Ozb4927NKGMpDXVatmwuBSuHZLYEeN3P2OKOb73Ih4kx AQ== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2v3vcfjegj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Sep 2019 03:53:31 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 19 Sep 2019 03:53:30 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.58) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 19 Sep 2019 03:53:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XLj4V1o5znAEf6cOENU+/hcWcO2LypL1lkRXKMFh45UwyjyOrTSWC+xmeSn57B4kkfLtikq98y8BNHPvKA+mNuZN29JfyNtFoEIG7Ly5RdlyOqhFuGx8P01zI79RPqANfAJAzXCjlOrXwdXDJo4Ma1/YfLgRUPRoj6J+xnqmpq0gb+qVpY2JI3lB7XEu8Kx/PX0cP0W2YVEAltgNDZ2CGVviFEfXBQNPMYOM1F8q91Wkq/+vpgOz/uQ3ybJ74Tv4vC0tkM9AGodLLJIofDkwJLiyie+RbKpY4L4hGBjwSmFAmi7ae9MO2iQ5n2EMF7AAMyPuO+o6FqJAcd/za64QGA== 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=upbw4JBZlNWlNEGAlVneaLyzboRlkk5OhwLON/rdMbI=; b=KsmJQZjItDk3dLIkGF7atiNbdiTB07Wqx1POFZgK8O0JIQmpLjY+S3VDYMBzcIzlqXUSy6srW4Dk5CWECSwpav8Du9EXkcompeY9kwkdxwdi/XzLeDUZc+dhb2RbZBBZShZzoqPaz1lFQxwGtwLlDSlWNU5dzBlwy0yGv4xHJVo3pgQqY8NrpPHtHlmNZGk6g50GZU34CKNaXoWBbKkccaNwcES0AzzI4l7ayHboZzqbCLMNGCXTg26xJwAaBdUZnCn/l2cThOFdSCkMGv+wwIO1/1ID6kMlMFuCz5cifYhe6nx7vcORB5ZivJzSJgbPvgCmxvQZCfVjmcdKVmzFew== 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=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=upbw4JBZlNWlNEGAlVneaLyzboRlkk5OhwLON/rdMbI=; b=HmVgw0+qVOYT2l+9gE95d0zPhkc0VbBQqaILDBBuDhKwN4nMMWiqhQUoNYeBuZnFF/gwJUobHtn0sITNhfS2AMpuS5RyHJuu63QXab04cUaHftDerHdMJTa1YqCIIdisDvlzUCG2WEMPpPLrPSdcVoxXNPXDzZGQDdc2FAzOpds= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3376.namprd18.prod.outlook.com (10.255.238.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.16; Thu, 19 Sep 2019 10:53:27 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::5007:2282:4aff:5baa]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::5007:2282:4aff:5baa%7]) with mapi id 15.20.2263.023; Thu, 19 Sep 2019 10:53:27 +0000 From: Anoob Joseph To: "Ananyev, Konstantin" , "Smoczynski, MarcinX" , "akhil.goyal@nxp.com" CC: "dev@dpdk.org" , Narayana Prasad Raju Athreya , Jerin Jacob Kollanukkaran , Archana Muniganti Thread-Topic: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback session Thread-Index: AQHVYytvQTM+ragIcUyjA1ZmuGIqT6cxEoawgAAiKYCAAALJ0IAA4FuAgABIw8CAAFI9gIAALeSA Date: Thu, 19 Sep 2019 10:53:27 +0000 Message-ID: References: <20190814204847.15600-1-marcinx.smoczynski@intel.com> <20190904141642.14820-1-marcinx.smoczynski@intel.com> <2601191342CEEE43887BDE71AB9772580191966C6D@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191966FFC@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191967349@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772580191967349@irsmsx105.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.175.97.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 022c2771-97d0-463e-d27c-08d73cef99e8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB3376; x-ms-traffictypediagnostic: MN2PR18MB3376: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(366004)(136003)(39860400002)(346002)(13464003)(189003)(199004)(6116002)(561944003)(11346002)(446003)(110136005)(478600001)(102836004)(3846002)(4326008)(66066001)(107886003)(7696005)(71200400001)(53546011)(6506007)(2501003)(99286004)(71190400001)(186003)(2906002)(52536014)(316002)(81156014)(76116006)(54906003)(14454004)(26005)(9686003)(66556008)(66476007)(33656002)(64756008)(256004)(476003)(66946007)(5660300002)(25786009)(8936002)(76176011)(55016002)(6436002)(81166006)(14444005)(66446008)(486006)(229853002)(74316002)(305945005)(8676002)(7736002)(86362001)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3376; 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-message-info: gMQFgxI7V2FC/bWytYxPfx1h0KdXZt0t3MxyWyzkopBdmUoU2GQGNofvhWc/39hIF7U4xcNyJUj3j96LLFTeyGSz+NHuPzrdiZzsfKOAC9h9uorL41RDv9kxZ27MDPopQ6FsBsfVUbyWFrDYBmaGDzgsCyVSYgVlkt86Zq6OT/1N+WtYlpUso22MsoBwirqs3FyHm66bSGIJSUDbDjhTpHRtNVfKIrnFFugt4c+TuMBkLg6zamAEkOU7kcniqIVztRAj/Wa8tkgKeCU30fCzDOM26FZXAakniZqg4Q3xGZUWYTAuBXqZZ45JO6jW6h5ybS2ofD04ZSarY92eG4PPIgE0HSHX/P2GYPZpgSrB3rbvrTxP4IO5dTv9hKD0zUJlYShkpPXnSz38FdSd1k50wpDG3neo70B+aAZU4BHKX+8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 022c2771-97d0-463e-d27c-08d73cef99e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 10:53:27.1358 (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: jTGP6DoFMESZVHRqz1AsvZ6XDeDgvRjPBoA5Wd3mTK8cGqVXF3pBceRqGn7emszWlqgcoYxhUhUNIrwVXuh7WA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3376 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-19_04:2019-09-18,2019-09-19 signatures=0 Subject: Re: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback session 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: Thursday, September 19, 2019 1:04 PM > To: Anoob Joseph ; Smoczynski, MarcinX > ; akhil.goyal@nxp.com > Cc: dev@dpdk.org; Narayana Prasad Raju Athreya ; > Jerin Jacob Kollanukkaran ; Archana Muniganti > > Subject: RE: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback > session >=20 >=20 > Hi Anoob, >=20 > > > > > > Sorry for the late response. But how do you plan to handle > > > > > > "inline > > > protocol" > > > > > processed packets? > > > > > > > > > > Right now that feature is supported for "inline crypto" only. > > > > > > > > [Anoob] The description says "inline processed" packets. Hence the > confusion. > > > > > > > > > For the case when SA doesn't enable replay window and/or ESN > > > > > current patch should also work for "inline proto" too, but this > > > > > is just my understanding (not tested, etc.). > > > > > > > > [Anoob] In case of inline ipsec processing, the ipsec state (which > > > > would track sequence number etc) will be internal to the PMDs. So > > > > anti- replay/ESN would have to be done either in the h/w or PMD. > > > > This would > > > mean application will not have state information regarding ipsec proc= essing. > > > Hence fallback handling with the above scheme will not work in that c= ase. > > > > > > Agree, that's why I wrote above that current wok might work for > > > inline-proto > > > *only* if replay window and ESN is disabled. > > > > [Anoob] Any feature that makes use of protocol "state" would fail with > > this scheme. In case of inline ipsec, that is anti-replay & ESN. I see > > that you are not planning for fallback session for outbound. If at all = that is > planned, this scheme will fail to co-ordinate sequence number between ori= ginal > and fallback sessions. >=20 > Right now we don't do outbound fallback sessions. > Again, similar scheme would work for TX with lookaside-none and inline-cr= ypto, > but not for inline/lookaside-proto. > Of course few extra changes would be needed - move fragmentation before > ipsec processing part. [Anoob] Understood. =20 >=20 > > > > > > > > > > > > > To address this properly for inline protocol, we will have to come > > > > up with some logic to share session private data b/w "eligible" > > > > PMDs. This would > > > involve library changes to rte_security, etc. > > > > > > Again, totally agree. > > > As I remember we already discussed it about a year ago, but didn't > > > come up with any concrete proposal. > > > > > > > Once that is proposed, there will be one kind of handling for > > > > inline protocol processing and another kind for inline crypto > > > > processing. Would you > > > be fine with that? > > > > > > For sure something needs to be changed for inline-proto to sync > > > replay- window/ESN related data between HW/PMD and SW. > > > What it should be - new function, or something else - hard to tell ri= ght now. > > > > [Anoob] No disagreement. My only concern is the incompleteness of this > solution. > > We will have to propose a totally new scheme for inline protocol. >=20 > Sure, looking forward for it. > In fact, I asked these questions a year ago but as I said before there wa= s no > progress on that. >=20 > > You do agree that this approach will not help inline protocol offloadin= g, right? >=20 > Yes, see above. >=20 > > If you are okay with having different solutions for inline crypto & > > inline protocol, I don't have any issue with this series. > > > > Also, how do you plan to pass "state" info to lookaside protocol > > session? That will be required to handle ESN/anti-replay in lookaside p= rotocol > capable PMD as well. >=20 > Obviously there is no such API for any *-proto devices, see above. > Not sure why do you keep repeating it, I already agreed with you, see abo= ve :) > Just to summarize: > 1. Yes I think for lookaiside/iniline-proto devices there is a need for s= ome extra > API > to sync session state between HW and SW. > Right now, I don't have a clear idea how exactly it should look like. > 2. Intel team doesn't plan to work on this API right now. > 3. I am happy to review with what you guys will come-up with and provide = my > feedback. > Hope that makes things clear. [Anoob] My apologies if the queries seemed repetitive. I guess all my conce= rns are answered. Please do update the logs (and description) to state limi= tations regarding protocol offloads. I would suggest using "inline crypto p= rocessing" instead of "inline processing" wherever applicable. Also, if loo= kaside protocol is mentioned, better state that the "protocol state" will h= ave to be maintained by application (or lib ipsec in case of lookaside ipse= c offload). =20 > Konstantin >=20 > > > > > Konstantin > > > > > > > > > > > > Konstantin > > > > > > > > > > > > > > > > > Thanks, > > > > > > Anoob > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: dev On Behalf Of Marcin > > > > > > > Smoczynski > > > > > > > Sent: Wednesday, September 4, 2019 7:47 PM > > > > > > > To: konstantin.ananyev@intel.com; akhil.goyal@nxp.com > > > > > > > Cc: dev@dpdk.org; Marcin Smoczynski > > > > > > > > > > > > > > Subject: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add > > > > > > > fallback session > > > > > > > > > > > > > > Inline processing is limited to a specified subset of traffic= . > > > > > > > It is often unable to handle more complicated situations, > > > > > > > such as fragmented traffic. When using inline processing > > > > > > > such traffic is > > > dropped. > > > > > > > > > > > > > > Introduce multiple sessions per SA allowing to configure a > > > > > > > fallback lookaside session for packets that normally would be > dropped. > > > > > > > A fallback session type in the SA configuration by adding 'fa= llback' > > > > > > > with 'lookaside-none' or 'lookaside-protocol' parameter to > > > > > > > determine type of session. > > > > > > > > > > > > > > Fallback session feature is available only when using librte_= ipsec. > > > > > > > > > > > > > > v1 to v2 changes: > > > > > > > - disable fallback offload for outbound SAs > > > > > > > - add test scripts > > > > > > > > > > > > > > Marcin Smoczynski (3): > > > > > > > examples/ipsec-secgw: ipsec_sa structure cleanup > > > > > > > examples/ipsec-secgw: add fallback session feature > > > > > > > examples/ipsec-secgw: add offload fallback tests > > > > > > > > > > > > > > doc/guides/sample_app_ug/ipsec_secgw.rst | 17 +- > > > > > > > examples/ipsec-secgw/esp.c | 35 ++-- > > > > > > > examples/ipsec-secgw/ipsec-secgw.c | 16 +- > > > > > > > examples/ipsec-secgw/ipsec.c | 99 ++++++--= --- > > > > > > > examples/ipsec-secgw/ipsec.h | 61 +++++-- > > > > > > > examples/ipsec-secgw/ipsec_process.c | 113 +++++++-= ---- > > > > > > > examples/ipsec-secgw/sa.c | 164 ++++++++= +++++----- > > > > > > > .../test/trs_aesgcm_common_defs.sh | 4 +- > > > > > > > .../trs_aesgcm_inline_crypto_fallback_defs.sh | 5 + > > > > > > > .../test/tun_aesgcm_common_defs.sh | 6 +- > > > > > > > .../tun_aesgcm_inline_crypto_fallback_defs.sh | 5 + > > > > > > > 11 files changed, 358 insertions(+), 167 deletions(-) > > > > > > > create mode > > > > > > > 100644 > > > > > > > examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_ > > > > > > > defs .sh create mode 100644 examples/ipsec- > > > > > > > secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh > > > > > > > > > > > > > > -- > > > > > > > 2.21.0.windows.1