From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id BC2BCA0548; Mon, 26 Apr 2021 03:47:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3A4A341131; Mon, 26 Apr 2021 03:47:58 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id 6DB2B41110 for ; Mon, 26 Apr 2021 03:47:56 +0200 (CEST) IronPort-SDR: LVdeA60xVjQATmb3MvZOHKqbFq9bEBt+RUK2DmdSKLroNrk7sdVd2ZbgGRQ9ebFjwYjdh6wlK1 eA9E4DKF3Xrg== X-IronPort-AV: E=McAfee;i="6200,9189,9965"; a="196379442" X-IronPort-AV: E=Sophos;i="5.82,250,1613462400"; d="scan'208";a="196379442" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2021 18:47:55 -0700 IronPort-SDR: ST/iWxJCqVxTBWJGJB2x1xLhg9smv3NhSIxF9u6bkkp+FOm5yAmeJ8cjacUw5nEwc6no1xPYZ9 W5rnzZr529Mw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,251,1613462400"; d="scan'208";a="456925026" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by fmsmga002.fm.intel.com with ESMTP; 25 Apr 2021 18:47:54 -0700 Received: from shsmsx603.ccr.corp.intel.com (10.109.6.143) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 25 Apr 2021 18:47:53 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX603.ccr.corp.intel.com (10.109.6.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 26 Apr 2021 09:47:52 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2106.013; Mon, 26 Apr 2021 09:47:51 +0800 From: "Zhang, Qi Z" To: "Zhang, Yuying" , "dev@dpdk.org" , "Wang, Haiyue" CC: "Yan, Zhirun" , "Guo, Junfeng" Thread-Topic: [PATCH v3 2/2] net/ice: refactor input set fields for switch filter Thread-Index: AQHXOdiOq5J2aohKwEeTs1gdB37XT6rGBcSA Date: Mon, 26 Apr 2021 01:47:51 +0000 Message-ID: References: <20210422100541.935478-1-yuying.zhang@intel.com> <20210425132906.976067-1-yuying.zhang@intel.com> <20210425132906.976067-2-yuying.zhang@intel.com> In-Reply-To: <20210425132906.976067-2-yuying.zhang@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 2/2] net/ice: refactor input set fields for switch filter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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: Zhang, Yuying > Sent: Sunday, April 25, 2021 9:29 PM > To: dev@dpdk.org; Zhang, Qi Z ; Wang, Haiyue > > Cc: Yan, Zhirun ; Guo, Junfeng > ; Zhang, Yuying > Subject: [PATCH v3 2/2] net/ice: refactor input set fields for switch fil= ter >=20 > Input set has been divided into inner and outer part to distinguish > different fields. However, the parse method of switch filter doesn't > match this update. Refactor switch filter to distingush inner and outer > input set in the same way as other filters. >=20 > Signed-off-by: Yuying Zhang > --- > drivers/net/ice/ice_switch_filter.c | 746 ++++++++++++---------------- > 1 file changed, 323 insertions(+), 423 deletions(-) >=20 >=20 ...... >=20 > -static uint64_t > -ice_switch_inset_get(const struct rte_flow_item pattern[], > +static bool > +ice_switch_parse_pattern(const struct rte_flow_item pattern[], > struct rte_flow_error *error, > struct ice_adv_lkup_elem *list, > uint16_t *lkups_num, > - enum ice_sw_tunnel_type *tun_type) > + enum ice_sw_tunnel_type *tun_type, > + const struct ice_pattern_match_item pattern_match_item) Better to parse const pointer, but not struct value const struct ice_pattern_match_item *pattern_match_item > { > const struct rte_flow_item *item =3D pattern; > enum rte_flow_item_type item_type; > @@ -504,7 +456,9 @@ ice_switch_inset_get(const struct rte_flow_item > pattern[], > const struct rte_flow_item_pfcp *pfcp_spec, *pfcp_mask; > const struct rte_flow_item_gtp *gtp_spec, *gtp_mask; > const struct rte_flow_item_gtp_psc *gtp_psc_spec, *gtp_psc_mask; > - uint64_t input_set =3D ICE_INSET_NONE; > + uint64_t outer_input_set =3D ICE_INSET_NONE; > + uint64_t inner_input_set =3D ICE_INSET_NONE; > + uint64_t *input =3D NULL; Why we need pointer here? Can we: if (tunnel_valid) { ... input_set =3D inner_input_set; } else { ... input_set =3D outer_input_set; }=20 ....... >=20 > - inputset =3D ice_switch_inset_get > - (pattern, error, list, &lkups_num, &tun_type); > - if ((!inputset && !ice_is_prof_rule(tun_type)) || > - (inputset & ~pattern_match_item->input_set_mask_o)) { > + if (ice_switch_parse_pattern(pattern, error, list, &lkups_num, > + &tun_type, *pattern_match_item) =3D=3D false) { No need "=3D=3Dfalse", use ! for Boolean. > rte_flow_error_set(error, EINVAL, > RTE_FLOW_ERROR_TYPE_ITEM_SPEC, > pattern, > -- > 2.25.1