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 0A6F5A0565; Mon, 23 Mar 2020 12:24:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D50791C06A; Mon, 23 Mar 2020 12:24:39 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 502C01C06A for ; Mon, 23 Mar 2020 12:24:37 +0100 (CET) IronPort-SDR: COrPdOeEktomt3gFGXmN7QlgJIFkRdqYp/p4B52FrMwaO5abTLKIg15fdKjhAXMcKUUHMJrmRf iMlAqGrfiYQA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2020 04:24:35 -0700 IronPort-SDR: D8432OeVkO0isS0da51YSKiZV7nNowPnQL1avYZhLxRUFrzH/wafsG8kVpvQ92xOm9801ynLWd wgvO+aW6dLiQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,296,1580803200"; d="scan'208";a="419470053" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga005.jf.intel.com with ESMTP; 23 Mar 2020 04:24:34 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 23 Mar 2020 04:24:34 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 23 Mar 2020 04:24:34 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.53) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 23 Mar 2020 04:24:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ka/TG2O1fkGsjpKImxoONMuNkHhDIyMsc98xOLkbmfzh4tARdu2l1X2tdMg7yZE8e0DNCfhGp6vPQQXBIBi7KYZ5Gh0/dNHdIUDB5fVxCiBv61N+82WLtIKbPD4cGJu3tHIgEUfMiMmX/534BhyUPq/R7WI1egNLyqY7WudqFbzTfF+TNp+1Oy1nT/k6s3DHInvwSG/qwQxCbSJW56cbqAFBAG1/eeSzxaAcy2GB2n5pPZKTW2qCtENNjnjZjeYwlCs10DYH2I/0W+4uol275m+b70aVSKEg4fr6hKeSlBm94Q6bL8xI9K32P0eI+NjlskT/pJJ5MUADNEjoL3EqKA== 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=iJH9s2+t063Z6T5c3aOYgBGM95g3tuKT72DiF3Dw9ZA=; b=WQ4vR2wHk8YxGXBF+IFiu9uVUcoX25dcPISx/FKC3h+HpZCB7hiP0WFSwWfwfB5cFCtXjoAwIpz0s+nQPubzjjR77ToxspOX/79n+GlftLbTjg0tBnpnBvBld8FjG1qnaK+5vWZVZ/8xKvyICJzNJnmPr+ZKgfoNyQ2WuHQhc9xkwqX2+8l3Ik/kn7eLKm16oHPhwADOFZtVwcvgMKHeTmH5p+unGxnYBgb4tOVqTBujWEiHGdnf2ZBX+0Lk1WtAbgWjLXlwTehOcRR86VALfkZtlEhvpYmrsupMHo8b5rqoWsktao3iqrwod6CTmvDIDfdBOlR86Q61iSVLbT9cFA== 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=iJH9s2+t063Z6T5c3aOYgBGM95g3tuKT72DiF3Dw9ZA=; b=uxbDf/QtoyD1Avn1T8nzqYfvMrs2QrJK/J9CpOSkIwKqzLMyvbn7BgQL9UFJK3gTr4/OlSFOAAY3U2MxD1GKqvj+GS9EHP1ePuBiYslNoT+fcZzg9+K0pXKYOEhLbj+KYUxWaw4z1+otEKgweymxLj3ZrA+m8Ehtzgb9gX+kutY= Received: from CY4PR1101MB2326.namprd11.prod.outlook.com (2603:10b6:903:b3::23) by CY4PR1101MB2133.namprd11.prod.outlook.com (2603:10b6:910:17::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Mon, 23 Mar 2020 11:24:31 +0000 Received: from CY4PR1101MB2326.namprd11.prod.outlook.com ([fe80::58c7:7df:1b11:9c56]) by CY4PR1101MB2326.namprd11.prod.outlook.com ([fe80::58c7:7df:1b11:9c56%4]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 11:24:31 +0000 From: "Shetty, Praveen" To: Anoob Joseph , "dev@dpdk.org" , "Doherty, Declan" , "Iremonger, Bernard" , "Ananyev, Konstantin" CC: Narayana Prasad Raju Athreya Thread-Topic: [dpdk-dev] [PATCH v2] examples/ipsec-secgw: support flow director feature Thread-Index: AQHV/gqmiyoUulcVKUK6c1eUyHQvZKhRIzsAgATgqIA= Date: Mon, 23 Mar 2020 11:24:31 +0000 Message-ID: References: <20200311145529.40221-1-praveen.shetty@intel.com> <20200319162145.28906-1-praveen.shetty@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzc0MmRhMjUtZmQwNi00NWZlLWExZTItYWRiYzVkMDZjYmI5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTm05VEdjNnFXUFdJNkhDMXBHVVRcL2t3MWU0S2RFQndjT2pEQUxLOU56MEJrYkhJemZ5OGxXZTFSWFhUck5hQlMifQ== 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=praveen.shetty@intel.com; x-originating-ip: [192.55.79.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d1a7c827-5f95-4c30-d458-08d7cf1cc1e8 x-ms-traffictypediagnostic: CY4PR1101MB2133: 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:10000; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(346002)(376002)(396003)(199004)(478600001)(186003)(33656002)(6636002)(26005)(30864003)(86362001)(64756008)(66446008)(66476007)(66556008)(71200400001)(9686003)(66946007)(76116006)(52536014)(55016002)(6506007)(53546011)(81156014)(81166006)(5660300002)(110136005)(316002)(8936002)(7696005)(4326008)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR1101MB2133; H:CY4PR1101MB2326.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: da26PgTMIRVbFEtmpMdCPg0c8lh18nid2VUpwVrtJCMuhV1Fvo5vkXopgYbmEJ528tMrfybq67mrL1AcrCVVkXmsU4+zcaesTEPL+h0V5GtrjDSNpccSNX+C8a2ZTo2gkDTOTPDxgkZ1il+xRH8nLD6C5umOi4p+ZtDnCgEQrD2HV1tbr+lVZRe98f1cU9X+EXlDzqO0q+T22foEyv/7qfaCqiyErWufU2fe4HQVFRJK2H+ayL6vw/Gvkpwb8Cnm+E9PEXZkNWTlfXYeBSZY6+oAf1JXvkRoZ2VuCMsY33yS6i+jRLQbwG1+uHIM2AR+nmjSgOe1WDykaKQSMfUje3Uu+j4MOndlbC9xH56PaAcfsVWXtKik18Ip7iiGt0T5JkSznFNdqGXxNFFmmJUWVPpBkhRsdB38wdGk0HYW/9xDVDDDTMt+RdB8HLd29eXK x-ms-exchange-antispam-messagedata: w5iy84YDMocNWWE9dcFM8M4s8mxP8zzpv2ZgtSL5x0a1zayYv4BK8ef4uGEgK9GIVCCFfSEkd+byoZXElZPWQR1dyvYdsZW5ZqsRTRd87HfYBKg0GoMZ6PPeo3iTei7jf46qGLqV12XaDxSZOOn6tA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d1a7c827-5f95-4c30-d458-08d7cf1cc1e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 11:24:31.2990 (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: 1e7AxS5CdeKJ2gcYTJDpFYpGPtdLJyVyD3UC+RrMPpqB92ll85kCq3FlVd4tlpQAWwiT4PDQV9wPVyzEx+U0AMUyg6kW9XbLa8aGDzTzME8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2133 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2] examples/ipsec-secgw: support flow director feature 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 Anoob, Thank you. Please see my response inline. Regards, Praveen -----Original Message----- From: Anoob Joseph =20 Sent: Friday, March 20, 2020 1:45 PM To: Shetty, Praveen ; dev@dpdk.org; Doherty, Decl= an ; bernard.iremonger@intel.co; Ananyev, Konstan= tin Cc: Narayana Prasad Raju Athreya Subject: RE: [dpdk-dev] [PATCH v2] examples/ipsec-secgw: support flow direc= tor feature Hi Praveen, You need to rebase to the latest dpdk-next-crypto code base. This patch is = not applying cleanly. [Praveen] Will fix this in V3. There were few patches from Intel removing the existing FDIR and adding som= e new implementation. Hope this patch takes that also into account. Also, w= hy do we need to call the feature flow director. I would assume rte_flow pe= r SA is what is being attempted here. [Praveen] In regards the action name, it wasn't trying to be flow director = specific, but the name was trying to capture the action which was flow dire= ction to a specific queue. We're open to change this to whatever is deemed = appropriate ... perhaps just "flow-queue-action " or "distrubte ? Few comments. See inline. Thanks, Anoob > -----Original Message----- > From: dev On Behalf Of Praveen Shetty > Sent: Thursday, March 19, 2020 9:52 PM > To: dev@dpdk.org; declan.doherty@intel.com;=20 > bernard.iremonger@intel.co; konstantin.ananyev@intel.com > Subject: [dpdk-dev] [PATCH v2] examples/ipsec-secgw: support flow=20 > director feature >=20 > Support load distribution in security gateway application using NIC=20 > load distribution feature(Flow Director). > Flow Director is used to redirect the specified inbound ipsec flow to=20 > a specified queue.This is achieved by extending the SA rule syntax to=20 > support specification by adding new action_type of to=20 > a specified . >=20 > Signed-off-by: Praveen Shetty > --- > v2 changes: > added more details in commit message. > added a check to throw an error if the security session type is other=20 > than LOOKASIDE_NONE >=20 > examples/ipsec-secgw/ep0.cfg | 11 +++++ > examples/ipsec-secgw/ipsec-secgw.c | 56 ++++++++++++++++++++++++- > examples/ipsec-secgw/ipsec.c | 67 ++++++++++++++++++++++++++++++ > examples/ipsec-secgw/ipsec.h | 11 +++++ > examples/ipsec-secgw/sa.c | 60 +++++++++++++++++++++++++- > 5 files changed, 202 insertions(+), 3 deletions(-) >=20 > diff --git a/examples/ipsec-secgw/ep0.cfg=20 > b/examples/ipsec-secgw/ep0.cfg index dfd4aca7d..6f8d5aa53 100644 > --- a/examples/ipsec-secgw/ep0.cfg > +++ b/examples/ipsec-secgw/ep0.cfg > @@ -29,6 +29,7 @@ sp ipv4 in esp protect 111 pri 1 dst=20 > 192.168.186.0/24 sport > 0:65535 dport 0:6553 sp ipv4 in esp protect 115 pri 1 dst=20 > 192.168.210.0/24 sport > 0:65535 dport 0:65535 sp ipv4 in esp protect 116 pri 1 dst=20 > 192.168.211.0/24 sport 0:65535 dport 0:65535 sp ipv4 in esp protect=20 > 115 pri 1 dst > 192.168.210.0/24 sport 0:65535 dport 0:65535 > +sp ipv4 in esp protect 117 pri 1 dst 192.168.212.0/24 sport 0:65535=20 > +dport 0:65535 > sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535=20 > dport 0:65535 sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24=20 > sport 0:65535 dport 0:65535 sp ipv4 in esp protect 126 pri 1 dst=20 > 192.168.66.0/24 sport 0:65535 dport 0:65535 @@ -61,6 +62,8 @@ sp ipv6=20 > in esp protect 125 pri 1 dst > ffff:0000:0000:0000:aaaa:aaaa:0000:0000/96 > sport 0:65535 dport 0:65535 > sp ipv6 in esp protect 126 pri 1 dst > ffff:0000:0000:0000:bbbb:bbbb:0000:0000/96 \ sport 0:65535 dport=20 > 0:65535 > +sp ipv6 in esp protect 127 pri 1 dst > +ffff:0000:0000:0000:cccc:dddd:0000:0000/96 \ sport 0:65535 dport > +0:65535 >=20 > #SA rules > sa out 5 cipher_algo aes-128-cbc cipher_key=20 > 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \ @@ -118,6 +121,9 @@ dst 172.16.1.5 >=20 > sa in 116 cipher_algo null auth_algo null mode ipv4-tunnel src=20 > 172.16.2.6 dst > 172.16.1.6 >=20 > +sa in 117 cipher_algo null auth_algo null mode ipv4-tunnel src > +172.16.2.7 \ dst 172.16.1.7 flow-direction 0 2 > + > sa in 125 cipher_algo aes-128-cbc cipher_key=20 > c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:\ > c3:c3:c3:c3:c3 auth_algo sha1-hmac auth_key=20 > c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:c3:\ > c3:c3:c3:c3:c3:c3:c3:c3:c3 mode ipv6-tunnel \ @@ -130,6 +136,11 @@ sa=20 > in > 126 cipher_algo aes-128-cbc cipher_key=20 > 4d:4d:4d:4d:4d:4d:4d:4d:4d:4d:4d:\ > src 2222:2222:2222:2222:2222:2222:2222:6666 \ dst > 1111:1111:1111:1111:1111:1111:1111:6666 >=20 > +sa in 127 cipher_algo null auth_algo null mode ipv6-tunnel \ src > +2222:2222:2222:2222:2222:2222:2222:7777 \ dst > +1111:1111:1111:1111:1111:1111:1111:7777 \ flow-direction 0 3 > + > #Routing rules > rt ipv4 dst 172.16.2.5/32 port 0 > rt ipv4 dst 172.16.2.6/32 port 1 > diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-=20 > secgw/ipsec-secgw.c index 4799bc90c..132484422 100644 > --- a/examples/ipsec-secgw/ipsec-secgw.c > +++ b/examples/ipsec-secgw/ipsec-secgw.c > @@ -166,7 +166,6 @@ static const struct option lgopts[] =3D { > {CMD_LINE_OPT_FRAG_TTL, 1, 0, CMD_LINE_OPT_FRAG_TTL_NUM}, > {NULL, 0, 0, 0} > }; > - [Anoob] I would assume the above change is not intentional. [Praveen] it was not intentional. Will fix this in V3. =20 > /* mask of enabled ports */ > static uint32_t enabled_port_mask; > static uint64_t enabled_cryptodev_mask =3D UINT64_MAX; @@ -259,6=20 > +258,30 @@ static struct rte_eth_conf port_conf =3D { > .txmode =3D { > .mq_mode =3D ETH_MQ_TX_NONE, > }, > + .fdir_conf =3D { > + .mode =3D RTE_FDIR_MODE_NONE, > + .pballoc =3D RTE_FDIR_PBALLOC_64K, > + .status =3D RTE_FDIR_REPORT_STATUS, > + .mask =3D { > + .vlan_tci_mask =3D 0xFFEF, > + .ipv4_mask =3D { > + .src_ip =3D 0xFFFFFFFF, > + .dst_ip =3D 0xFFFFFFFF, > + }, > + .ipv6_mask =3D { > + .src_ip =3D {0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, > + 0xFFFFFFFF}, > + .dst_ip =3D {0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, > + 0xFFFFFFFF}, > + }, > + .src_port_mask =3D 0xFFFF, > + .dst_port_mask =3D 0xFFFF, > + .mac_addr_byte_mask =3D 0xFF, > + .tunnel_type_mask =3D 1, > + .tunnel_id_mask =3D 0xFFFFFFFF, > + }, > + .drop_queue =3D 127, > + } > }; >=20 > static struct socket_ctx socket_ctx[NB_SOCKETS]; @@ -1184,7 +1207,6=20 > @@ > main_loop(__attribute__((unused)) void *dummy) >=20 > if (nb_rx > 0) > process_pkts(qconf, pkts, nb_rx, portid); > - [Anoob] I would assume the above change is not intentional. [Praveen ] it was not intentional. Will fix this in V3. =20 > /* dequeue and process completed crypto-ops */ > if (UNPROTECTED_PORT(portid)) > drain_inbound_crypto_queues(qconf, > @@ -1196,6 +1218,27 @@ main_loop(__attribute__((unused)) void *dummy) > } > } >=20 > +int check_flow_params(uint16_t fdir_portid, uint8_t fdir_qid) { > + uint16_t i; > + uint16_t portid; > + uint8_t queueid; > + > + for (i =3D 0; i < nb_lcore_params; ++i) { > + portid =3D lcore_params_array[i].port_id; > + if (portid =3D=3D fdir_portid) { > + queueid =3D lcore_params_array[i].queue_id; > + if (queueid =3D=3D fdir_qid) > + break; > + } > + > + if (i =3D=3D nb_lcore_params - 1) > + return -1; > + } > + > + return 1; > +} > + > static int32_t > check_params(void) > { > @@ -2503,6 +2546,15 @@ main(int32_t argc, char **argv) > continue; >=20 > sa_check_offloads(portid, &req_rx_offloads, &req_tx_offloads); > + /* check if FDIR is configured on the port */ > + if (check_fdir_configured(portid)) { > + /* Enable FDIR */ > + port_conf.fdir_conf.mode =3D > RTE_FDIR_MODE_PERFECT; > + /* Disable RSS */ > + port_conf.rxmode.mq_mode =3D ETH_MQ_RX_NONE; > + port_conf.rx_adv_conf.rss_conf.rss_hf =3D 0; > + port_conf.rx_adv_conf.rss_conf.rss_key =3D NULL; > + } [Anoob] This would mean, once FDIR is enabled for one SA, then the port ini= t is changed. RSS is disabled and FDIR gets enabled. Can you confirm if I u= nderstood the code correctly? [Praveen] Currently this is correct but in the future the idea would be on= ly to disable the queue which the SA is associated with. =20 > port_init(portid, req_rx_offloads, req_tx_offloads); > } >=20 > diff --git a/examples/ipsec-secgw/ipsec.c=20 > b/examples/ipsec-secgw/ipsec.c index 6e8120702..363809cfd 100644 > --- a/examples/ipsec-secgw/ipsec.c > +++ b/examples/ipsec-secgw/ipsec.c > @@ -415,6 +415,73 @@ create_inline_session(struct socket_ctx *skt_ctx,=20 > struct ipsec_sa *sa, > return 0; > } >=20 > +int > +create_ipsec_esp_flow(struct ipsec_sa *sa) { [Anoob] Why just ESP? Can't the same rte_flow rules be used for doing BYPAS= S/TRANSPORT? [Praveen] So yes but this is all we have validated at the moment, transpor= t is trickier as it requires a reverse lookup of the SPD to get the SIP/DIP= , which we may do in the future. In terms of BYPASS is not SA specified so = we haven't looked at offloading the SPD yet. Finally AH isn't supported in = the GW so we haven't looked at it. =20 > + int ret =3D 0; > + struct rte_flow_error err; > + if (sa->direction =3D=3D RTE_SECURITY_IPSEC_SA_DIR_EGRESS) > + return 0; /* No Flow director rules for Egress traffic */ > + if (sa->flags =3D=3D TRANSPORT) { > + RTE_LOG(ERR, IPSEC, > + "No Flow director rule for transport mode:"); > + return -1; > + } > + sa->action[0].type =3D RTE_FLOW_ACTION_TYPE_QUEUE; > + sa->pattern[0].type =3D RTE_FLOW_ITEM_TYPE_ETH; > + sa->action[0].conf =3D > + &(struct rte_flow_action_queue){ > + .index =3D sa->fdir_qid, > + }; > + sa->attr.egress =3D 0; > + sa->attr.ingress =3D 1; > + if (IS_IP6(sa->flags)) { > + sa->pattern[1].mask =3D &rte_flow_item_ipv6_mask; > + sa->pattern[1].type =3D RTE_FLOW_ITEM_TYPE_IPV6; > + sa->pattern[1].spec =3D &sa->ipv6_spec; > + memcpy(sa->ipv6_spec.hdr.dst_addr, > + sa->dst.ip.ip6.ip6_b, IPV6_ADDR_LEN); > + memcpy(sa->ipv6_spec.hdr.src_addr, > + sa->src.ip.ip6.ip6_b, IPV6_ADDR_LEN); > + sa->pattern[2].type =3D RTE_FLOW_ITEM_TYPE_ESP; > + sa->pattern[2].spec =3D &sa->esp_spec; > + sa->pattern[2].mask =3D &rte_flow_item_esp_mask; > + sa->esp_spec.hdr.spi =3D rte_cpu_to_be_32(sa->spi); > + sa->pattern[3].type =3D RTE_FLOW_ITEM_TYPE_END; > + } else if (IS_IP4(sa->flags)) { > + sa->pattern[1].mask =3D &rte_flow_item_ipv4_mask; > + sa->pattern[1].type =3D RTE_FLOW_ITEM_TYPE_IPV4; > + sa->pattern[1].spec =3D &sa->ipv4_spec; > + sa->ipv4_spec.hdr.dst_addr =3D sa->dst.ip.ip4; > + sa->ipv4_spec.hdr.src_addr =3D sa->src.ip.ip4; > + sa->pattern[2].type =3D RTE_FLOW_ITEM_TYPE_ESP; > + sa->pattern[2].spec =3D &sa->esp_spec; > + sa->pattern[2].mask =3D &rte_flow_item_esp_mask; > + sa->esp_spec.hdr.spi =3D rte_cpu_to_be_32(sa->spi); > + sa->pattern[3].type =3D RTE_FLOW_ITEM_TYPE_END; > + } > + sa->action[1].type =3D RTE_FLOW_ACTION_TYPE_END; > + > + ret =3D rte_flow_validate(sa->fdir_portid, &sa->attr, > + sa->pattern, sa->action, > + &err); > + if (ret < 0) { > + RTE_LOG(ERR, IPSEC, > + "Flow Validation failed\n"); > + return ret; > + } > + sa->flow =3D rte_flow_create(sa->fdir_portid, > + &sa->attr, sa->pattern, sa->action, > + &err); > + if (!sa->flow) { > + RTE_LOG(ERR, IPSEC, > + "Flow Creation failed\n"); > + return -1; > + } > + > + return 0; > +} > + > /* > * queue crypto-ops into PMD queue. > */ > diff --git a/examples/ipsec-secgw/ipsec.h=20 > b/examples/ipsec-secgw/ipsec.h index 4f2fd6184..00147895a 100644 > --- a/examples/ipsec-secgw/ipsec.h > +++ b/examples/ipsec-secgw/ipsec.h > @@ -46,6 +46,8 @@ >=20 > #define IP6_VERSION (6) >=20 > +#define IPV6_ADDR_LEN 16 [Anoob] Can't we do a sizeof of some structure to get the same? Having an a= pplication specific macro may not be the right approach. [Praveen] okay. Wil fix this in V3. =20 > + > struct rte_crypto_xform; > struct ipsec_xform; > struct rte_mbuf; > @@ -138,6 +140,9 @@ struct ipsec_sa { > }; > enum rte_security_ipsec_sa_direction direction; > uint16_t portid; > + uint16_t fdir_portid; [Anoob] The existing member 'portid' above 'fdir_portid' is used for a simi= lar rte_flow creation for inline IPsec. Can't we use the same here also? [Praveen] Will check if we can use the existing member. > + uint8_t fdir_qid; > + uint8_t fdir_flag; >=20 > #define MAX_RTE_FLOW_PATTERN (4) > #define MAX_RTE_FLOW_ACTIONS (3) > @@ -383,5 +388,11 @@ create_lookaside_session(struct ipsec_ctx=20 > *ipsec_ctx, struct ipsec_sa *sa, int create_inline_session(struct=20 > socket_ctx *skt_ctx, struct ipsec_sa *sa, > struct rte_ipsec_session *ips); > +int > +check_flow_params(uint16_t fdir_portid, uint8_t fdir_qid); > + > +int > +create_ipsec_esp_flow(struct ipsec_sa *sa); >=20 > +int check_fdir_configured(uint16_t portid); [Anoob] Better to stick to the convention followed. [Praveen] Will fix this in V3. =20 > #endif /* __IPSEC_H__ */ > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c=20 > index 4822d6bda..204a685fb 100644 > --- a/examples/ipsec-secgw/sa.c > +++ b/examples/ipsec-secgw/sa.c > @@ -20,6 +20,9 @@ > #include > #include > #include > +#include > +#include > +#include >=20 > #include "ipsec.h" > #include "esp.h" > @@ -271,6 +274,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens, > uint32_t type_p =3D 0; > uint32_t portid_p =3D 0; > uint32_t fallback_p =3D 0; > + int16_t status_p =3D 0; >=20 > if (strcmp(tokens[0], "in") =3D=3D 0) { > ri =3D &nb_sa_in; > @@ -681,6 +685,38 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens, > fallback_p =3D 1; > continue; > } > + if (strcmp(tokens[ti], "flow-direction") =3D=3D 0) { > + if (ips->type =3D=3D > + > RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL || > + ips->type =3D=3D > + RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > || > + ips->type =3D=3D > + > RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL || > + ips->type =3D=3D > + > RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO) { > + APP_CHECK(0, status, "Flow Director not " > + "supported for security session " > + "type:%d", ips->type); > + return; > + } > + rule->fdir_flag =3D 1; > + INCREMENT_TOKEN_INDEX(ti, n_tokens, status); > + if (status->status < 0) > + return; > + rule->fdir_portid =3D atoi(tokens[ti]); > + INCREMENT_TOKEN_INDEX(ti, n_tokens, status); > + if (status->status < 0) > + return; > + rule->fdir_qid =3D atoi(tokens[ti]); > + /* validating portid and queueid */ > + status_p =3D check_flow_params(rule->fdir_portid, > + rule->fdir_qid); > + if (status_p < 0) { > + printf("port id %u / queue id %u is not valid\n", > + rule->fdir_portid, rule->fdir_qid); > + } > + continue; > + } >=20 > /* unrecognizeable input */ > APP_CHECK(0, status, "unrecognized input \"%s\"", @@ -823,6 > +859,9 @@ print_one_sa_rule(const struct ipsec_sa *sa, int inbound) > break; > } > } > + if (sa->fdir_flag =3D=3D 1) > + printf("flow-direction %d %d", sa->fdir_portid, sa->fdir_qid); > + > printf("\n"); > } >=20 > @@ -1153,7 +1192,12 @@ sa_add_rules(struct sa_ctx *sa_ctx, const=20 > struct ipsec_sa entries[], > return -EINVAL; > } > } > - > + if (sa->fdir_flag && inbound) { > + rc =3D create_ipsec_esp_flow(sa); > + if (rc !=3D 0) > + RTE_LOG(ERR, IPSEC_ESP, > + "create_ipsec_esp flow failed\n"); > + } > print_one_sa_rule(sa, inbound); > } >=20 > @@ -1256,6 +1300,20 @@ fill_ipsec_session(struct rte_ipsec_session=20 > *ss, struct rte_ipsec_sa *sa) > return rc; > } >=20 > +int > +check_fdir_configured(uint16_t portid) { > + struct ipsec_sa *sa =3D NULL; > + uint32_t idx_sa =3D 0; > + > + for (idx_sa =3D 0; idx_sa < nb_sa_in; idx_sa++) { > + sa =3D &sa_in[idx_sa]; > + if (sa->fdir_portid =3D=3D portid) > + return sa->fdir_flag; > + } > + return 0; > +} > + > /* > * Initialise related rte_ipsec_sa object. > */ > -- > 2.17.1