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 1FE73A2EDB for ; Sun, 29 Sep 2019 16:29:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 355D02B88; Sun, 29 Sep 2019 16:29:14 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id B9A711F28 for ; Sun, 29 Sep 2019 16:29:12 +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 x8TEPo3p007629; Sun, 29 Sep 2019 07:29:11 -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=bMbhfO5MP7L1cANvWgCENzNRE3sJHNRqrhYo7OWlutQ=; b=ms9sUUmo7FeL8dawIxwOol6daiWVfgfmb+IJZVsTuue3r8cy/yRZE9+S7DY9TXCLsyFe 3jWdIKjufB7UDEuEjKX4eBb2aKWG243hUrWjTh0lXcPJz2leuqHpwWVQCdiNEIFglp24 nQTN2Ew1YrMGYXtHWjxEan4rRJJ810rLnzVn1XX4TupvyjlWFUDfnfRlDzp2kb2CbWVk JYUfX5odQKihu1Q4DszToFNdLcUy646GJ7w7tI6WVqIMgMxm+N4A494sXvFTjubgKj8q CO88dQNpP/bE+QHxQVswFVUbihhGry8I7QruDGl0x8Qp+dQ7nnwJCViki3zUJXeExAYt bQ== Received: from sc-exch02.marvell.com ([199.233.58.182]) by mx0b-0016f401.pphosted.com with ESMTP id 2va71mb5rr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 29 Sep 2019 07:29:11 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 29 Sep 2019 07:29:10 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (104.47.42.54) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Sun, 29 Sep 2019 07:29:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n0t6uGM/eAaDHReCyQ6Bc1M2ZYHW20sEz1NhL+RRWRkz24Zwr86yAg/CjJCKR4wBkjhRHtfAjQzOuq4IGKUoYaDRcQQ8mxlPCIoVQzKwVRdrocpEia/ujDBO/RWTmcb8mEPG+o4A4htxp6d/Audd44GZaQsh9wmPH8iJz5i/xzsQ6euKpQrPccMfjDWTYaykgVdiONlQW397urwlIXJvG0hxkU1nfecY2VeXfl4X+IKY8SnXkEXGzdzaR6xghTFdk8po7yUH/C3vFAU5ZDG6KrS4E0NpuN7l1FQX7QaF0ZxOa7EjF6yaz4fMHMR3vTdtY3tNkE069k6cT/VVdgjrqA== 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=bMbhfO5MP7L1cANvWgCENzNRE3sJHNRqrhYo7OWlutQ=; b=R6m4xAYhXQ4P2KAX6DnWaURHc5rBaUS0B2BqY7tQuRoMsYUtGOSEPDQSJf7UKq10QD7/fsi1TIW4HgVdnV/p2qmjH9gLSG/YSSKvOkpwdCkfl+txfT7MH3iX50lTzBaIcZo0oiouZ/LVLyqncRGWXqNR7R1QYds9FDn9/nb3IWyeDlKn4O53M6RXqGFLZwvhhiWplu2xN7qbOimuzOd8RJHoV9anWb3H2IbEDMYKS+vmfPzmxaLBBg10JL5cbO4oFVcaYx8pk1+zgQed2TE02zmHkaceEg8uYo+rFXId2BvhVQSnzmL131bQbzTa44zN1z9Kz9bGehJei5xnCqzSKA== 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=bMbhfO5MP7L1cANvWgCENzNRE3sJHNRqrhYo7OWlutQ=; b=biOI/UooO2of0VCUJ8v4K54Gp9alb5PRaLvArGPslLQkbiRsNbuxYvqw6PMReS30kEUUStaOYj/aZNy5O5AnaYkl8Yivcj0l9LFBBuB/MAP5MzCxo59ChyDTMU7Eu4m2F42mfmasAnju1B4JtVab9Kz1X/jgGSUE8JA7OJJj0GA= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2974.namprd18.prod.outlook.com (20.179.20.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Sun, 29 Sep 2019 14:29:08 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::6d15:3367:4c9:5385]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::6d15:3367:4c9:5385%7]) with mapi id 15.20.2305.017; Sun, 29 Sep 2019 14:29:07 +0000 From: Anoob Joseph To: "Ananyev, Konstantin" , "Smoczynski, MarcinX" , "akhil.goyal@nxp.com" CC: "dev@dpdk.org" , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Archana Muniganti Thread-Topic: [dpdk-dev] [PATCH v3 0/3] add fallback session Thread-Index: AQHVcgRo85zyvQn15EqlYfBjRx4gCqc9gzWQgABnUACAAOcWgA== Date: Sun, 29 Sep 2019 14:29:07 +0000 Message-ID: References: <20190904141642.14820-1-marcinx.smoczynski@intel.com> <20190923114415.17932-1-marcinx.smoczynski@intel.com> <2601191342CEEE43887BDE71AB977258019196B087@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258019196B087@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.85.60] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98abeb2c-dc14-410f-6c5b-08d744e96341 x-ms-traffictypediagnostic: MN2PR18MB2974: x-ms-exchange-purlcount: 2 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:91; x-forefront-prvs: 017589626D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39850400004)(346002)(366004)(396003)(376002)(189003)(199004)(13464003)(4326008)(86362001)(14454004)(966005)(478600001)(476003)(55016002)(9686003)(6306002)(6436002)(486006)(25786009)(107886003)(6246003)(2906002)(54906003)(110136005)(71200400001)(71190400001)(316002)(5660300002)(256004)(14444005)(3846002)(6116002)(52536014)(81156014)(81166006)(8936002)(66066001)(76116006)(229853002)(66556008)(66946007)(8676002)(64756008)(66446008)(76176011)(7696005)(6506007)(99286004)(53546011)(102836004)(11346002)(446003)(186003)(26005)(74316002)(7736002)(305945005)(2501003)(66476007)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2974; 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: tw9RKETrA8oXtj6unGpeyM5or+5vbYueYS7Hn6LyLmRtiVTv90o3TCcrS5zBN5myuYNPthPcgiODAS/qF6P+eVO3nhBvN4jqswFLNx/PW018EPC/6oIBeYSxHqhKHiuqNzmK6H5tffr7dzlWGjRiotPiLoXQWnMEZjKCU2Zhiv2nZyBO0gwMey7IJCU5F6uULN5DgD2M+RFovZPspzpPLR7/7UCLdFftAZccXNPrOo2sascPhEMpa+p0dRQo5w0wWwojj0OWihXlSlzp9nwsESbdBaj0USK6RLvgth27nKmrMQJwdoAf+HK0Oxr4wszwoS9FLbMNAuKpaRViPFKDj+nSczkPFrown3XBrM3xAGMKjO8YFoJC98fdQbUbTftdpH8pwofoPdneJATIoBjv4fQY+A0BTD1hp3hdBAhw3XH0khdL9iXjQGL0B8FUnXoJbWjBRHZHXF3Nidkpk9mMRA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 98abeb2c-dc14-410f-6c5b-08d744e96341 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2019 14:29:07.8335 (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: 8fKN52w9p1hHToWsZi14t9qph32K3Oin5agWxIi5+H8z+EfTqKsBGBVRm3C1AMQS4Uhvru/IyDE/9AnPz6YGZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2974 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-29_09:2019-09-25,2019-09-29 signatures=0 Subject: Re: [dpdk-dev] [PATCH v3 0/3] 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 26, 2019 6:08 PM > To: Anoob Joseph ; Smoczynski, MarcinX > ; akhil.goyal@nxp.com > Cc: dev@dpdk.org; Jerin Jacob Kollanukkaran ; Narayan= a > Prasad Raju Athreya ; Archana Muniganti > > Subject: RE: [dpdk-dev] [PATCH v3 0/3] add fallback session >=20 >=20 > Hi Anoob, > Answers/comments inline. > Marcin, please correct me, if I missed something. > Konstantin >=20 > > > > Hi Marcin, Konstantin, > > > > I've few more observations regarding the proposed feature. > > > > 1. From what I understood, if an ESP packet ends up on an unprotected > > interface and doesn't have 'PKT_RX_SEC_OFFLOAD' bit set, then the packe= t > would be looked up to see the associated SA and then fallback session is = figured > out and then further processing is done. > > > > Can you confirm if I understood the sequence correctly? If yes, then > > aren't we doing an extra lookup in the s/w? The packet may be looked > > by the h/w using rte_flow and that information could be used to determi= ne the > SA. Also, if the ESP packet is expected to be forwarded, then the above l= ogic will > add an unnecessary lookup even after your h/w has detected that the packe= t > need not be security processed. >=20 > Not sure I understood your whole statement above. > AFAIK, right now (with dpdk master) for unprotected iface it works like t= hat: >=20 > 1. slit incoming traffic into 3 groups: ESP packets, IPv4 packets, IPv6 = packets. > For ESP packets: > 2. perform SAD lookup > a. if it fails (non SA found for that SPI), then drop the packet. > b. otherwise (SA found) process the packet using found SA >=20 > What fall-back patch adds: > Before step 2.b check: > does that SA has its primary session with type INLINE-CRYPTO and > does HW fail to do IPsec realted processing for it (by some reason)? > If yes, then mark this packet to be processed by fall-back session. > if (MBUF_NO_SEC_OFFLOAD(pkt) && sa->fallback_sessions > 0) { > uintptr_t intsa =3D (uintptr_t)sa; > intsa |=3D IPSEC_SA_OFFLOAD_FALLBACK_FLAG; > result_sa =3D (void *)intsa; } >=20 > So from my perspective, no additional lookup where introduced. [Anoob] For inline processing, h/w does a lookup and figures out the securi= ty processing to be done on the packet. "rte_security_get_userdata()" allow= s s/w to further segregate that info. In this approach, I believe we don't = consider how such info from h/w can be used. =20 > Also AFAIK, right now there is no possibility to configure ipsec-secgw to= BYPASS > some ESP traffic. > Should we do it (to conform to ipsec RFC) - that's probably subject of an= other > discussion. [Anoob] The approach (choice of flags) forces a software-based SA lookup fo= r packets that need to be bypassed instead of leveraging possible hardware = SA lookup. I don't think what ipsec-secgw does matters here. For example, ESN was not supported by ipsec-secgw (before library mode was = introduced), but every single library change and application change was add= ed keeping in mind that ESN is a valid feature for ipsec. So it is one thin= g to say ipsec-secgw doesn't support ESP bypass and saying the solution doe= sn't consider a possibility of ESP bypass.=20 =20 >=20 > > > > 2. The solution proposed here seems like adding the handling in > > ipsec-secgw instead of ipsec library. In other words, this feature is n= ot getting > added in ipsec library, which was supposed to simplify the whole ipsec us= age in > DPDK, but fails to handle the case of fragmentation. >=20 > What we have right now with ipsec library is SA (low) level API. > It can handle multi-segment packets properly, but expects someone else to= do > other steps (fragmentation/reassembly). > ipsec-secgw demonstrates how librte_ip_frag and librte_ipsec can be used > together to deal with fragmented IPsec traffic in a proper manner. > Probably in future we'll consider adding some high-level API that will be= able to > do whole processing under hood (SPD/SAD lookup, fragment/reassembly, actu= al > IPsec packet processing, matching inbound selectors, etc.), but right now= it is > not the case. >=20 > > Also, since the fallback feature is entirely done in the application, i= t begs the > question why the same feature is omitted for legacy use case. >=20 > Because legacy mode doesn't support multi-seg packets at first place. > Also it is an extra overhead to support 2 code-paths (legacy and library)= for the > same app, so we'd like in future to deprecate and later remove legacy cod= e- > path. > As a first step we propose to make library code-path a default one: > http://patches.dpdk.org/cover/58247/ [Anoob] Even if we need the application to do the reassembly, it would look= simple if application uses the same "rte_ipsec_session" to process the fal= lback packet. In that case, the processing required to handle the other pac= ket will be hidden from the application. Here application has to make sure = it chooses the correct session, which I believe should be moved to ipsec li= brary. >=20 > > > > 3. It seems like ordering won't be maintained once this processing is > > done. Again, this is the sequence I understood. Please correct me if I = missed > something, > > a. Application receives a bunch of packets (let's say 6 > > packets), in which few are fragmented (P3 & P4) and the rest can be inl= ine > processed. > > b. Application receives P1->P2->P3->P4->P5->P6 (in this, P1, P2,= P5, P6 are > inline processed successfully) and P4 & P5 are the fragments > > c. Application groups packets. P1->P2->P5->P6 becomes one group = and P3- > >P4 becomes another and goes for fallback processing. > > Now how is ordering maintained? I couldn't figure out how that is done = in this > case. >=20 > You right, fallback session can introduce packet reordering. > At least till we'll have ability to process packets in sync mode too. > See our presentation at dpdk userspace (slides 17, 18): > https://static.sched.com/hosted_files/dpdkbordeaux2019/8f/DPDK-IPSECu9.pd= f > Right now the only way to deal with it - have replay window big enough to > sustain reordering and async processing latency. > That's actually another reason why we add this feature into ipsec-secgw s= ample > app: > so people can evaluate it on their platforms, determine what replay windo= w size > would be needed, what issues/slowdowns it might cause, etc. [Anoob] This is something I had noticed while going through the code flow. = The ordering info is lost because of the approach. As we dig deeper, the fe= ature looks hardly complete. The concerning part is the approach doesn't se= em conducive to fixing any of these issues in the future. Also, if the new ipsec related features are introduced via ipsec-secgw than= via rte_ipsec, then it raises doubts over the utility of rte_ipsec library= . =20 >=20 > > > > Thanks, > > Anoob > > > > > -----Original Message----- > > > From: dev On Behalf Of Marcin Smoczynski > > > Sent: Monday, September 23, 2019 5:14 PM > > > To: Anoob Joseph ; akhil.goyal@nxp.com; > > > konstantin.ananyev@intel.com > > > Cc: dev@dpdk.org; Marcin Smoczynski > > > Subject: [dpdk-dev] [PATCH v3 0/3] add fallback session > > > > > > Add fallback session feature allowing to process packets that inline > > > processor is unable to handle (e.g. fragmented traffic). Processing > > > takes place in a secondary session defined for SA in a configuration = file. > > > > > > This feature is limited to ingress IPsec traffic only. IPsec > > > anti-replay window and ESN are supported in conjunction with > > > fallback session when following conditions are met: > > > * primary session is 'inline-crypto-offload, > > > * fallback sessions is 'lookaside-none'. > > > > > > v2 to v3 changes: > > > - doc and commit log update - explicitly state feature limitations > > > > > > 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 | 20 ++- > > > 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, 361 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.17.1