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 2994AA0350; Mon, 29 Jun 2020 03:55:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9752E2C2B; Mon, 29 Jun 2020 03:55:44 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 787101150; Mon, 29 Jun 2020 03:55:42 +0200 (CEST) IronPort-SDR: wHpGRU2Kc+3Gomp1tL0hBU5vUPCTRkyT57ktUZr0G4gi/UZH9I/a0RFdHTSMZrojSSEnUtd1GP irqLnqTrAk+g== X-IronPort-AV: E=McAfee;i="6000,8403,9666"; a="163908723" X-IronPort-AV: E=Sophos;i="5.75,293,1589266800"; d="scan'208";a="163908723" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2020 18:55:41 -0700 IronPort-SDR: 9XdRm7k+8L8kBhIq255D6xFXH+9gfOZ7D1xSWdXdS/xiwJVaJs6fAl4daLmIJWYl1WFULQdW0O 4QXRKGaw5dTg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,293,1589266800"; d="scan'208";a="320512143" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 28 Jun 2020 18:55:40 -0700 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 28 Jun 2020 18:55:38 -0700 Received: from shsmsx108.ccr.corp.intel.com (10.239.4.97) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 28 Jun 2020 18:55:38 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.89]) by SHSMSX108.ccr.corp.intel.com ([169.254.8.185]) with mapi id 14.03.0439.000; Mon, 29 Jun 2020 09:55:35 +0800 From: "Zhang, Qi Z" To: "Zhao1, Wei" , "dev@dpdk.org" CC: "stable@dpdk.org" , "Lu, Nannan" Thread-Topic: [PATCH v3 3/4] net/ice: support switch flow for specific L4 type Thread-Index: AQHWTQy9jgBHveIt1k6Y2J43WI7kb6ju1YJA Date: Mon, 29 Jun 2020 01:55:34 +0000 Message-ID: <039ED4275CED7440929022BC67E7061154847C39@SHSMSX103.ccr.corp.intel.com> References: <20200617061429.6447-1-wei.zhao1@intel.com> <20200628050145.72810-1-wei.zhao1@intel.com> <20200628050145.72810-4-wei.zhao1@intel.com> In-Reply-To: <20200628050145.72810-4-wei.zhao1@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 3/4] net/ice: support switch flow for specific L4 type 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" > -----Original Message----- > From: Zhao1, Wei > Sent: Sunday, June 28, 2020 1:02 PM > To: dev@dpdk.org > Cc: stable@dpdk.org; Zhang, Qi Z ; Lu, Nannan > ; Zhao1, Wei > Subject: [PATCH v3 3/4] net/ice: support switch flow for specific L4 type >=20 > This patch add more specific tunnel type for ipv4/ipv6 packet, it enable > tcp/udp layer of ipv4/ipv6 as L4 payload but without > L4 dst/src port number as input set for the switch filter rule. >=20 > Fixes: 47d460d63233 ("net/ice: rework switch filter") > Cc: stable@dpdk.org >=20 > Signed-off-by: Wei Zhao > --- > drivers/net/ice/ice_switch_filter.c | 27 ++++++++++++++++++++------- > 1 file changed, 20 insertions(+), 7 deletions(-) >=20 > diff --git a/drivers/net/ice/ice_switch_filter.c > b/drivers/net/ice/ice_switch_filter.c > index c607e8d17..c1ea74c73 100644 > --- a/drivers/net/ice/ice_switch_filter.c > +++ b/drivers/net/ice/ice_switch_filter.c > @@ -29,6 +29,8 @@ > #define ICE_PPP_IPV4_PROTO 0x0021 > #define ICE_PPP_IPV6_PROTO 0x0057 > #define ICE_IPV4_PROTO_NVGRE 0x002F > +#define ICE_TUN_VXLAN_VALID 0x0001 > +#define ICE_TUN_NVGRE_VALID 0x0002 Why not apply the same pattern with other valid flag? I mean use vxlan_valid and nvgre_valid. Could be tunnel_valid =3D vxlan_valid | nvgre_valid. >=20 > #define ICE_SW_INSET_ETHER ( \ > ICE_INSET_DMAC | ICE_INSET_SMAC | ICE_INSET_ETHERTYPE) @@ > -471,11 +473,11 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > const struct rte_flow_item_l2tpv3oip *l2tp_spec, *l2tp_mask; > const struct rte_flow_item_pfcp *pfcp_spec, *pfcp_mask; > uint64_t input_set =3D ICE_INSET_NONE; > + uint16_t tunnel_valid =3D 0; > bool pppoe_elem_valid =3D 0; > bool pppoe_patt_valid =3D 0; > bool pppoe_prot_valid =3D 0; > bool profile_rule =3D 0; > - bool tunnel_valid =3D 0; > bool ipv6_valiad =3D 0; > bool ipv4_valiad =3D 0; > bool udp_valiad =3D 0; > @@ -924,7 +926,7 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > return 0; > } >=20 > - tunnel_valid =3D 1; > + tunnel_valid =3D ICE_TUN_VXLAN_VALID; > if (vxlan_spec && vxlan_mask) { > list[t].type =3D ICE_VXLAN; > if (vxlan_mask->vni[0] || > @@ -960,7 +962,7 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > "Invalid NVGRE item"); > return 0; > } > - tunnel_valid =3D 1; > + tunnel_valid =3D ICE_TUN_NVGRE_VALID; > if (nvgre_spec && nvgre_mask) { > list[t].type =3D ICE_NVGRE; > if (nvgre_mask->tni[0] || > @@ -1325,6 +1327,21 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > *tun_type =3D ICE_SW_TUN_PPPOE; > } >=20 > + if (*tun_type =3D=3D ICE_NON_TUN) { > + if (tunnel_valid =3D=3D ICE_TUN_VXLAN_VALID) > + *tun_type =3D ICE_SW_TUN_VXLAN; > + else if (tunnel_valid =3D=3D ICE_TUN_NVGRE_VALID) > + *tun_type =3D ICE_SW_TUN_NVGRE; > + else if (ipv4_valiad && tcp_valiad) > + *tun_type =3D ICE_SW_IPV4_TCP; > + else if (ipv4_valiad && udp_valiad) > + *tun_type =3D ICE_SW_IPV4_UDP; > + else if (ipv6_valiad && tcp_valiad) > + *tun_type =3D ICE_SW_IPV6_TCP; > + else if (ipv6_valiad && udp_valiad) > + *tun_type =3D ICE_SW_IPV6_UDP; > + } > + > *lkups_num =3D t; >=20 > return input_set; > @@ -1536,10 +1553,6 @@ ice_switch_parse_pattern_action(struct > ice_adapter *ad, >=20 > for (; item->type !=3D RTE_FLOW_ITEM_TYPE_END; item++) { > item_num++; > - if (item->type =3D=3D RTE_FLOW_ITEM_TYPE_VXLAN) > - tun_type =3D ICE_SW_TUN_VXLAN; > - if (item->type =3D=3D RTE_FLOW_ITEM_TYPE_NVGRE) > - tun_type =3D ICE_SW_TUN_NVGRE; > if (item->type =3D=3D RTE_FLOW_ITEM_TYPE_ETH) { > const struct rte_flow_item_eth *eth_mask; > if (item->mask) > -- > 2.19.1