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 D1C33A0350; Mon, 22 Jun 2020 17:36:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D9FBC1D8E5; Mon, 22 Jun 2020 17:36:27 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 9574F1D8DE; Mon, 22 Jun 2020 17:36:25 +0200 (CEST) IronPort-SDR: ZIKO7T+c4agENmfF9oQMEv1Id/5ruU6GFOH04dX1sfphARkF4aQJsiZZtXel+r3vlTk8k9KzRk MW7rZCrQRB3Q== X-IronPort-AV: E=McAfee;i="6000,8403,9659"; a="132217529" X-IronPort-AV: E=Sophos;i="5.75,267,1589266800"; d="scan'208";a="132217529" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2020 08:36:23 -0700 IronPort-SDR: 89Q8H3SDZBZUozWauQ9A4Pm+b2XtHcNt0lxXDjeSi066CvKPreLFyVorlLByoVBDTzLWOBlrls kMhEAR7sQLdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,267,1589266800"; d="scan'208";a="353492444" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 22 Jun 2020 08:36:23 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 22 Jun 2020 08:36:22 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 22 Jun 2020 08:36:22 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.89]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.85]) with mapi id 14.03.0439.000; Mon, 22 Jun 2020 23:36:19 +0800 From: "Zhang, Qi Z" To: "Zhao1, Wei" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH v2 4/4] net/ice: support switch flow for specific L4 type Thread-Index: AQHWRHIJP/PPx+2L10qF1Z+f+H6dHKjky3TQ Date: Mon, 22 Jun 2020 15:36:19 +0000 Message-ID: <039ED4275CED7440929022BC67E706115484301E@SHSMSX103.ccr.corp.intel.com> References: <20200605074031.16231-1-wei.zhao1@intel.com> <20200617061429.6447-1-wei.zhao1@intel.com> <20200617061429.6447-5-wei.zhao1@intel.com> In-Reply-To: <20200617061429.6447-5-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 v2 4/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: Wednesday, June 17, 2020 2:14 PM > To: dev@dpdk.org > Cc: stable@dpdk.org; Zhang, Qi Z ; Zhao1, Wei > > Subject: [PATCH v2 4/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 | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) >=20 > diff --git a/drivers/net/ice/ice_switch_filter.c > b/drivers/net/ice/ice_switch_filter.c > index 3b38195d6..f4fd8ff33 100644 > --- a/drivers/net/ice/ice_switch_filter.c > +++ b/drivers/net/ice/ice_switch_filter.c > @@ -471,11 +471,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; why not vxlan_valid and nvgre_valid to keep consistent naming with other va= riables? Can we use a bitmap =20 > 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; > @@ -960,7 +960,7 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > "Invalid NVGRE item"); > return 0; > } > - tunnel_valid =3D 1; > + tunnel_valid =3D 2; > if (nvgre_spec && nvgre_mask) { > list[t].type =3D ICE_NVGRE; > if (nvgre_mask->tni[0] || > @@ -1325,6 +1325,21 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > *tun_type =3D ICE_SW_TUN_PPPOE; > } >=20 > + if (!pppoe_patt_valid) { > + if (tunnel_valid =3D=3D 1) > + *tun_type =3D ICE_SW_TUN_VXLAN; > + else if (tunnel_valid =3D=3D 2) > + *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 +1551,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