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 736D9A046B for ; Tue, 25 Jun 2019 15:48:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7D4EF1B9C0; Tue, 25 Jun 2019 15:48:31 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 65D981B96E for ; Tue, 25 Jun 2019 15:48:30 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2019 06:48:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,416,1557212400"; d="scan'208";a="163628579" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga007.fm.intel.com with ESMTP; 25 Jun 2019 06:48:28 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 25 Jun 2019 06:48:28 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 25 Jun 2019 06:48:28 -0700 Received: from hasmsx112.ger.corp.intel.com (10.184.198.40) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 25 Jun 2019 06:48:27 -0700 Received: from HASMSX110.ger.corp.intel.com ([169.254.6.40]) by HASMSX112.ger.corp.intel.com ([169.254.11.200]) with mapi id 14.03.0439.000; Tue, 25 Jun 2019 16:48:25 +0300 From: "Drost, MariuszX" To: Akhil Goyal , "Nicolau, Radu" , "Lu, Wenzhuo" , "Ananyev, Konstantin" CC: "dev@dpdk.org" Thread-Topic: [PATCH 2/2] examples/ipsec-secgw: fix not working inline ipsec modes Thread-Index: AQHVGr3EYDfpkSdhFUCR9fxuipZzOaakatiAgAfdSACAADbVUA== Date: Tue, 25 Jun 2019 13:48:24 +0000 Message-ID: <3BB8A5892AABB64DA03CD11BE7165E2B075539C5@HASMSX110.ger.corp.intel.com> References: <20190604100644.13724-1-mariuszx.drost@intel.com> <20190604100644.13724-3-mariuszx.drost@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, About your comments: 1) I used macros around sa->flags where it was needed. Not all checks for t= hat set of flags use information if it is transport mode. As for macro WITH= OUT_TRANSPORT_VERSION, it was set only for checks that required information= from set of flags without taking into account new transport flags -> I can= set it in more places (like initialization stage), but I do not see a poin= t of that, besides being uniform. 2) WITHOUT_TRANSPORT_VERSION is a macro which masks sa->flags as they were = before change. It cuts newly proposed flags for transport mode, so behavior= of switches, where such flags were used before as variable, is unchanged. = I will provide a comment to the macro. I will provide patch as soon as possible (probably tomorrow). Kind regards, Mariusz Drost. -----Original Message----- From: Akhil Goyal [mailto:akhil.goyal@nxp.com]=20 Sent: Tuesday, June 25, 2019 3:15 PM To: Akhil Goyal ; Drost, MariuszX ; Nicolau, Radu ; Lu, Wenzhuo ; Ananyev, Konstantin Cc: dev@dpdk.org Subject: RE: [PATCH 2/2] examples/ipsec-secgw: fix not working inline ipsec= modes 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=20 > > for > > IPv6 both transport and tunnel mode. > > > > IPv6 tunnel mode is not working due to wrongly assigned fields of=20 > > security association patterns, as it was IPv4, during creation of=20 > > inline crypto session. > > > > IPv6 and IPv4 transport mode is iterating through security=20 > > capabilities until it reaches tunnel, which causes session to be=20 > > created as tunnel, instead of transport. Another issue, is that=20 > > config file does not provide source and destination ip addresses for=20 > > transport mode, which are required by NIC to perform inline crypto.=20 > > It uses default addresses stored in security association (all=20 > > zeroes), which causes dropped packages. > > > > To fix that, reorganization of code in create_session() is needed,=20 > > to behave appropriately to given protocol (IPv6/IPv4). Change in=20 > > iteration through security capabilities is also required, to check=20 > > 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=20 > > tunnel mode. Difference is that they are obtained from sp rules,=20 > > instead of config file. To do that, sp[4/6]_spi_present() function=20 > > is used to find addresses based on spi value, and then stored in=20 > > corresponding sa rule. This approach assumes, that every sp rule for=20 > > inline crypto have valid addresses, as well as range of addresses is=20 > > 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=20 > > change all checks done on these flags, so they work as expected. > > > > Fixes: ec17993a145a ("examples/ipsec-secgw: support security=20 > > 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 +++-- =20 > > 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=20 > > 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=20 > > ipsec_sa *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 @@=20 > > 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=20 > > 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=20 > defined macros. Could you please update this at all places, so that it=20 > will be uniform 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 ".=20 > could 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