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 C9055A0583; Fri, 20 Mar 2020 09:15:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F12592BBD; Fri, 20 Mar 2020 09:15:11 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 705D62BB9 for ; Fri, 20 Mar 2020 09:15:09 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02K8BHrF006070; Fri, 20 Mar 2020 01:15:08 -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=UFWlImPuxBJXispJjEY9AF9z8BjVFIt+CZh5F8pcmyU=; b=E8hwT3YyqUGk6preyt26Abj9wo/FHF12rFz3d5c8wGg7kXh1fL4lJ2lHfL8LgUS0NfQN obiHVT8u8l8UEzw093t7JhL8aELD89F9l3sf8BuDMzVuZ7G+LVyU6ySa2e4FUXQlYOJd u2OPhR5d9NXO8hI5PPvzqn5tZ+gCX35tqj5CWuGMo/32RJz8ux8JCIfepR+oM4CqDWxp 2AabDhCgbPyba7Q56ExJMWBPdOpnucmmDgPqppssBorcIMPyMaljDbeDa1nbygcLOQXE WXtj+K0TglL9+iho2Ooqgj+hmxFy5JOqY0qnSErOCsvJu14rOYtjHLS5d6i/yHsgJy/8 8A== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2yu8pqvast-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 01:15:08 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 20 Mar 2020 01:15:06 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.168) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 20 Mar 2020 01:15:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8sDW1qaUUwTQltAmai2Yd54eCE7MCMUXiVqtQHkw34bEBz4Q0AHLVUBB4VYRi79Vf/C/rvaA2uooMerKCgnGyV68A53pBX1jAQ6bf3InUzL1+qnP8LauyNhnBHeMalqoV1tXqeDZi+UciZOsm+/kvDev6jTPTI7dQESDUMeIkPujpVnvQnkRmAPNrYRme4B9yusPQ6E1XQsKJ7Y1LTSIw8X3Hh/KCAMSZ0gUQZ8fXqCJRGgJGFLzNyo55o4QFk0WqXqEc4Du5j+gGjiVEOpsIezfJN6myJ5B0Vdv2oaauqTNLspznGSwNTpEGZ0OcAmKWtR4oB2xqdLAOUXjOnp/Q== 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=UFWlImPuxBJXispJjEY9AF9z8BjVFIt+CZh5F8pcmyU=; b=EPW6Kv2hlJDBCnGe6iYki9L2bgTbq8HhJ/5JMUSIiw61tuxmp3oW2dC34bujtbxqhok5Hy9pKR3PlSWektmQW9iqCXjnLq5Azn2mNMcweb1toG9qdp1UrqEsqxgg91MT+z589VYPdxVdCNOC79j1DsLJmgB/26awqnoQpxeYM91gRlBQiu00ywR8P1ndDhR3jsNHHRC8It2WcfZXNWmvmEwhnmqqXmJBNBFcnwsyZcY2zPkk0y9SMuXBJdIeE9ENdlvKvP+JX8e4RnZzTd+FghPmlc5U6S95o+XL9xpkpv+olRZNQunVoIaXhuMQd6HBqylbqfBrT712umjl9+b0kA== 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=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UFWlImPuxBJXispJjEY9AF9z8BjVFIt+CZh5F8pcmyU=; b=iN8CjKlnOieqhD2jmiJnuuGoGAg7qFGlX3u2cY47okvnn11QAy+29nvp44/+sKdY2ZyMH1l1fv7zmg6pXSvibLgBTOhxtdrJd8EkpRqFXevSyWVmFY9S8QXy/IMoJj9L/awBHaQutkY6F++KdQgZTWkem4oXIN+S+aMkTgvGPuo= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (2603:10b6:208:3b::26) by MN2PR18MB3311.namprd18.prod.outlook.com (2603:10b6:208:162::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.18; Fri, 20 Mar 2020 08:15:04 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::648f:e7fa:f95e:191b]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::648f:e7fa:f95e:191b%2]) with mapi id 15.20.2814.021; Fri, 20 Mar 2020 08:15:04 +0000 From: Anoob Joseph To: Praveen Shetty , "dev@dpdk.org" , "declan.doherty@intel.com" , "bernard.iremonger@intel.co" , "konstantin.ananyev@intel.com" CC: Narayana Prasad Raju Athreya Thread-Topic: [dpdk-dev] [PATCH v2] examples/ipsec-secgw: support flow director feature Thread-Index: AQHV/gqIQF0C8KX2zES0vW5AbXvxjahRFcwg Date: Fri, 20 Mar 2020 08:15:04 +0000 Message-ID: References: <20200311145529.40221-1-praveen.shetty@intel.com> <20200319162145.28906-1-praveen.shetty@intel.com> In-Reply-To: <20200319162145.28906-1-praveen.shetty@intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [34.98.205.116] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0d18a20-c44e-46ce-9b51-08d7cca6cb99 x-ms-traffictypediagnostic: MN2PR18MB3311: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03484C0ABF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(396003)(366004)(136003)(199004)(186003)(53546011)(110136005)(4326008)(71200400001)(107886003)(7696005)(6506007)(30864003)(33656002)(478600001)(26005)(316002)(81166006)(81156014)(2906002)(52536014)(5660300002)(55016002)(8936002)(9686003)(66446008)(66476007)(66556008)(64756008)(66946007)(76116006)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3311; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; 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: bwLz8tSafuMQnz/2/rdIDjV4gqUOFHFFKZWAMNjFrkOXpyjznhKOUWxrOX0y/k9gCk4PwwN0QIMsp4gdL+Bhs4Jki6kLtOcFf8p1bX4giFUbF6IHhRxquTf+miYj3S94DgIkv9lgYuKMtyDvZGirxJTEJWmc8lskH8uXKH345g/OSSO532zK01E3GFnh8reRnIdUlDRoL2vNRbnHsuIWnD2+6/I7rg4uJHfq5um3Qtgur3JXEYSWOACZmOn4imy65DVPTmh6G5b4tC0KuDwsqYp4BdXii5X/mdCYWdYof5MxDi4wXy7zMJCLnI6uMWp687et4yDSvXBi3kldwyzeda9ENSysDSkxzn3+OSZOMtFyT+PZ71YmpRu93v/dWn2M3/lc+ZIklrPca9qLzP8Lu9WAY3SM29Vo5VLSR0fYNfBQXcRh2rTl9+Dv1Oattjvy x-ms-exchange-antispam-messagedata: xekhXYZsjxrc+90ENNlOC6VCzq4VTCzEWnfB242d80GZnPatAN4HUcLMWcItupJq+5vNHyYQoeshRl3U6DQ4C12oKqCU2xIR45WWjUJAPONGv7g/uynT4+wNdxI/WoSFxIZ+dMNQveO7bJ42GEc+XQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d0d18a20-c44e-46ce-9b51-08d7cca6cb99 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2020 08:15:04.7524 (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: m1XSIbgisq6rjM14t77KTyUnpPfT996elGakw2dDibIo2CWWJLnIwITDsohosLGJQobmARmM2+aNBZ+S9TmTuQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3311 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-20_01:2020-03-19, 2020-03-20 signatures=0 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 Praveen, You need to rebase to the latest dpdk-next-crypto code base. This patch is = not applying cleanly. 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. 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; bernard.iremonger@intel.co; > konstantin.ananyev@intel.com > Subject: [dpdk-dev] [PATCH v2] examples/ipsec-secgw: support flow directo= r > feature >=20 > Support load distribution in security gateway application using NIC load > distribution feature(Flow Director). > Flow Director is used to redirect the specified inbound ipsec flow to a s= pecified > queue.This is achieved by extending the SA rule syntax to support specifi= cation > by adding new action_type of to 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 tha= n > 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 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 192.168.186.0/24 s= port > 0:65535 dport 0:6553 sp ipv4 in esp protect 115 pri 1 dst 192.168.210.0/= 24 sport > 0:65535 dport 0:65535 sp ipv4 in esp protect 116 pri 1 dst 192.168.211.0= /24 > sport 0:65535 dport 0:65535 sp ipv4 in esp protect 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 > +dport 0:65535 > sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport= 0:65535 > sp ipv4 in esp protect 125 pri 1 dst 192.168.65.0/24 sport 0:65535 dport = 0:65535 > sp ipv4 in esp protect 126 pri 1 dst 192.168.66.0/24 sport 0:65535 dport = 0:65535 > @@ -61,6 +62,8 @@ sp ipv6 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 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 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 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 c3:c3:c3:c3:c3:c3:c3:c3:c3:= c3:c3:\ > c3:c3:c3:c3:c3 auth_algo sha1-hmac auth_key > 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 in > 126 cipher_algo aes-128-cbc cipher_key 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- > 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. =20 > /* mask of enabled ports */ > static uint32_t enabled_port_mask; > static uint64_t enabled_cryptodev_mask =3D UINT64_MAX; @@ -259,6 +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 @@ > 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. =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? =20 > port_init(portid, req_rx_offloads, req_tx_offloads); > } >=20 > diff --git a/examples/ipsec-secgw/ipsec.c 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, > 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? =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 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. =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? =20 > + 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 *ipsec_ctx= , > struct ipsec_sa *sa, int create_inline_session(struct socket_ctx *skt_c= tx, 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. =20 > #endif /* __IPSEC_H__ */ > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c 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 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 *ss, s= truct > 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