From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id BC8B7A046B for ; Tue, 25 Jun 2019 15:14:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E1A6C1B9FB; Tue, 25 Jun 2019 15:14:44 +0200 (CEST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30047.outbound.protection.outlook.com [40.107.3.47]) by dpdk.org (Postfix) with ESMTP id 813021B9E1 for ; Tue, 25 Jun 2019 15:14:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AZCfRT0SnPCErYxIKetOj3wBzIuc9p1ploYt28zWCR4=; b=UJbUgbrW0GsOngtgSRTm2d4FtAfi2ZOw5j16+W2EqikcbjtbDnSGJNwYmjK9dx4ZBydB3dRjzYz/OepvGCm7WMzJfe/ImIixQyvBKKksXJw8M8r7NR040kkl7HV9ucjHEuVR7ZKHV+Rj0azFUn4y/5UBT0PpLd5lEQL7diYDEwM= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6621.eurprd04.prod.outlook.com (20.179.235.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Tue, 25 Jun 2019 13:14:42 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::a929:3d03:7bb7:d5e0]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::a929:3d03:7bb7:d5e0%7]) with mapi id 15.20.2008.014; Tue, 25 Jun 2019 13:14:42 +0000 From: Akhil Goyal To: Akhil Goyal , Mariusz Drost , "radu.nicolau@intel.com" , "wenzhuo.lu@intel.com" , "konstantin.ananyev@intel.com" CC: "dev@dpdk.org" Thread-Topic: [PATCH 2/2] examples/ipsec-secgw: fix not working inline ipsec modes Thread-Index: AQHVGr3DdcEXM2VZZU+3H8wl2EMgbqakm8kAgAfeY7A= Date: Tue, 25 Jun 2019 13:14:42 +0000 Message-ID: References: <20190604100644.13724-1-mariuszx.drost@intel.com> <20190604100644.13724-3-mariuszx.drost@intel.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d7a626f-e21e-4d31-14db-08d6f96f15f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6621; x-ms-traffictypediagnostic: VE1PR04MB6621: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(396003)(366004)(136003)(189003)(199004)(66476007)(316002)(81166006)(6116002)(64756008)(2201001)(66066001)(229853002)(14454004)(66446008)(55016002)(71200400001)(11346002)(7736002)(8676002)(4326008)(53936002)(2906002)(81156014)(6436002)(68736007)(8936002)(305945005)(9686003)(486006)(102836004)(73956011)(7696005)(76116006)(66556008)(6506007)(26005)(52536014)(74316002)(33656002)(44832011)(86362001)(5660300002)(99286004)(478600001)(71190400001)(186003)(476003)(66946007)(3846002)(2501003)(256004)(14444005)(6246003)(446003)(110136005)(76176011)(25786009)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6621; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DF5Wosjr7ykC8i+f+Q6AizhB+A/GEeuL8zMba4f2w4bHNOIefOmzUm7u9CQ8OMllmV961G2SPMNY7BcSr7Uool8oSJdxezuwY2fPcUfFcX4MJi0aBkgMbQkem+vPktTWq3bq+FZsqCdzZWy+c44VEGGrqj/61hKP2viLnV3iewmmovsKu5grPnoc+ViCnWVBmWh+83KZKFGuUyop8Zs/DalzDR38mcHRkFvequ+0jpfoXA0dAcssnsRhQKqlatJuHL8YbFx46ReTgiCZJi/7IbzqZiQZW4E2RfVgAPprq3NBt+P+C6n31XxWque4gXxlE/VTChCIN+Frh4N2885zkzvbRCawYiL0U8W2ezyqfuHxe2VhxDXqNaYorzVdoPt+5i3eVdtkC4plkUwc6WHAHOR5Kc3AHG+luN7RonIIK6U= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d7a626f-e21e-4d31-14db-08d6f96f15f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 13:14:42.2996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: akhil.goyal@nxp.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6621 Subject: Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: fix not working inline ipsec modes 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 Marius, Could you please send the updated patch soon, so that they can be applied b= efore RC1. Thanks, Akhil >=20 > Hi Marius, >=20 >=20 > > Application ipsec-secgw is not working for IPv4 transport mode and for > > IPv6 both transport and tunnel mode. > > > > IPv6 tunnel mode is not working due to wrongly assigned fields of > > security association patterns, as it was IPv4, during creation of > > inline crypto session. > > > > IPv6 and IPv4 transport mode is iterating through security capabilities > > until it reaches tunnel, which causes session to be created as tunnel, > > instead of transport. Another issue, is that config file does not > > provide source and destination ip addresses for transport mode, which > > are required by NIC to perform inline crypto. It uses default addresses > > stored in security association (all zeroes), which causes dropped > > packages. > > > > To fix that, reorganization of code in create_session() is needed, > > to behave appropriately to given protocol (IPv6/IPv4). Change in > > iteration through security capabilities is also required, to check > > for expected mode (not only tunnel). > > > > For lack of addresses issue, some resolving mechanism is needed. > > Approach is to store addresses in security association, as it is > > for tunnel mode. Difference is that they are obtained from sp rules, > > instead of config file. To do that, sp[4/6]_spi_present() function > > is used to find addresses based on spi value, and then stored in > > corresponding sa rule. This approach assumes, that every sp rule > > for inline crypto have valid addresses, as well as range of addresses > > is not supported. > > > > New flags for ipsec_sa structure are required to distinguish between > > IPv4 and IPv6 transport modes. Because of that, there is need to > > change all checks done on these flags, so they work as expected. > > > > Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload") > > Fixes: 9a0752f498d2 ("net/ixgbe: enable inline IPsec") > > > This is a very well written description. Thanks. This helps in review of = the patch. >=20 > I have a few small comments, rest all is fine. >=20 > > Signed-off-by: Mariusz Drost > > --- > > examples/ipsec-secgw/esp.c | 12 +-- > > examples/ipsec-secgw/ipsec.c | 19 +++-- > > examples/ipsec-secgw/ipsec.h | 21 +++++- > > examples/ipsec-secgw/sa.c | 142 ++++++++++++++++++++++++++--------- > > examples/ipsec-secgw/sp4.c | 24 +++++- > > examples/ipsec-secgw/sp6.c | 42 ++++++++++- > > 6 files changed, 205 insertions(+), 55 deletions(-) > > > > diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c > > index f11d095ba..764e08dcf 100644 > > --- a/examples/ipsec-secgw/esp.c > > +++ b/examples/ipsec-secgw/esp.c > > @@ -192,7 +192,7 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_s= a > > *sa, > > } > > } > > > > - if (unlikely(sa->flags =3D=3D TRANSPORT)) { > > + if (unlikely(IS_TRANSPORT(sa->flags))) { > > ip =3D rte_pktmbuf_mtod(m, struct ip *); > > ip4 =3D (struct ip *)rte_pktmbuf_adj(m, > > sizeof(struct rte_esp_hdr) + sa->iv_len); > > @@ -233,13 +233,13 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa > > *sa, > > > > ip4 =3D rte_pktmbuf_mtod(m, struct ip *); > > if (likely(ip4->ip_v =3D=3D IPVERSION)) { > > - if (unlikely(sa->flags =3D=3D TRANSPORT)) { > > + if (unlikely(IS_TRANSPORT(sa->flags))) { > > ip_hdr_len =3D ip4->ip_hl * 4; > > nlp =3D ip4->ip_p; > > } else > > nlp =3D IPPROTO_IPIP; > > } else if (ip4->ip_v =3D=3D IP6_VERSION) { > > - if (unlikely(sa->flags =3D=3D TRANSPORT)) { > > + if (unlikely(IS_TRANSPORT(sa->flags))) { > > /* XXX No option headers supported */ > > ip_hdr_len =3D sizeof(struct ip6_hdr); > > ip6 =3D (struct ip6_hdr *)ip4; > > @@ -258,13 +258,13 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa > > *sa, > > pad_len =3D pad_payload_len + ip_hdr_len - rte_pktmbuf_pkt_len(m); > > > > RTE_ASSERT(sa->flags =3D=3D IP4_TUNNEL || sa->flags =3D=3D IP6_TUNNEL= || > > - sa->flags =3D=3D TRANSPORT); > > + IS_TRANSPORT(sa->flags)); > I can see that at multiple places, sa->flags are accessed without your de= fined > macros. Could you please update this at all places, so that it will be un= iform > across the application. >=20 > > > > if (likely(sa->flags =3D=3D IP4_TUNNEL)) > > ip_hdr_len =3D sizeof(struct ip); > > else if (sa->flags =3D=3D IP6_TUNNEL) > > ip_hdr_len =3D sizeof(struct ip6_hdr); > > - else if (sa->flags !=3D TRANSPORT) { > > + else if (!IS_TRANSPORT(sa->flags)) { > > RTE_LOG(ERR, IPSEC_ESP, "Unsupported SA flags: 0x%x\n", > > sa->flags); > > return -EINVAL; > > @@ -291,7 +291,7 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa *s= a, > > rte_prefetch0(padding); > > } > > > > - switch (sa->flags) { > > + switch (WITHOUT_TRANSPORT_VERSION(sa->flags)) { > I do not get the intent of this macro " WITHOUT_TRANSPORT_VERSION ". coul= d > you explain this in comments or some better name of the macro. >=20 > > case IP4_TUNNEL: > > ip4 =3D ip4ip_outbound(m, sizeof(struct rte_esp_hdr) + sa->iv_len, > > &sa->src, &sa->dst); >=20 >=20 > Regards, > Akhil