All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cao, Yahui" <yahui.cao@intel.com>
To: "Yan, Zhirun" <zhirun.yan@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Wang, Xiao W" <xiao.w.wang@intel.com>,
	 "Su, Simei" <simei.su@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1] net/ice: refactor flow pattern parser
Date: Tue, 17 Nov 2020 15:31:40 +0000	[thread overview]
Message-ID: <567972babaca49939efeebe98859eb50@intel.com> (raw)
In-Reply-To: <20201117084524.3610038-1-zhirun.yan@intel.com>

Hi Zhirun,

         I think it is great to refactor ice fdir to differentiate inner and outer field vector in a more clear way. Thanks for your commit.
         It seems there still needs some effort to complete this patch.

> -----Original Message-----
> From: Yan, Zhirun <zhirun.yan@intel.com>
> Sent: Tuesday, November 17, 2020 4:45 PM
> To: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>; Cao, Yahui <yahui.cao@intel.com>; Wang, Xiao W <xiao.w.wang@intel.com>;
> Su, Simei <simei.su@intel.com>
> Cc: Yan, Zhirun <zhirun.yan@intel.com>
> Subject: [PATCH v1] net/ice: refactor flow pattern parser
> 
> Distinguish inner/outer fields. And avoid too many nested conditionals
> in each type's parser.
[Cao, Yahui] 
Since this is quite a huge refactor, could you give a more detailed description in the commit message? Thanks.
It would be better if you can make them a patchset.

> 
> Signed-off-by: Zhirun Yan <zhirun.yan@intel.com>
> ---
>  drivers/net/ice/ice_fdir_filter.c | 504 ++++++++++++++++--------------
>  1 file changed, 269 insertions(+), 235 deletions(-)
> 
> diff --git a/drivers/net/ice/ice_fdir_filter.c b/drivers/net/ice/ice_fdir_filter.c
> index 175abcdd5c..b53ed30b1c 100644
> --- a/drivers/net/ice/ice_fdir_filter.c
> +++ b/drivers/net/ice/ice_fdir_filter.c
> @@ -1646,7 +1646,9 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter *ad,
>  	const struct rte_flow_item_vxlan *vxlan_spec, *vxlan_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 = ICE_INSET_NONE;
> +	uint64_t inner_input_set = ICE_INSET_NONE;
> +	uint64_t outer_input_set = ICE_INSET_NONE;
> +	uint64_t *input_set;
>  	uint8_t flow_type = ICE_FLTR_PTYPE_NONF_NONE;
>  	uint8_t  ipv6_addr_mask[16] = {
>  		0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
> @@ -1655,289 +1657,315 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter *ad,
>  	uint32_t vtc_flow_cpu;
>  	uint16_t ether_type;
>  	enum rte_flow_item_type next_type;
> +	bool is_outer = true;
> +	struct ice_fdir_extra *p_ext_data;
> +	struct ice_fdir_v4 *p_v4;
> +	struct ice_fdir_v6 *p_v6;
> 
> +	for (item = pattern; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> +		if (item->type == RTE_FLOW_ITEM_TYPE_VXLAN) {
> +			tunnel_type = ICE_FDIR_TUNNEL_TYPE_VXLAN;
> +			break;
> +		}
[Cao, Yahui] 
You should take both of VXLAN and GTP cases into consideration
> +	}
> +
> +	/* This loop parse flow pattern and distinguish Non-tunnel and tunnel
> +	 * flow. For tunnel flow, reuse non-tunnel structure to track inner
> +	 * part.
> +	 *
> +	 *        is_outer tunnel_type p_input_set input_set_bit data_struct
> +	 * Non-Tun    Y         N         inner        outer        origin
> +	 * Tun-out    Y         Y         outer        outer        outer
> +	 * Tun-in     N         Y         inner        inner        origin
> +	 */
>  	for (item = pattern; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
>  		if (item->last) {
>  			rte_flow_error_set(error, EINVAL,
> -					RTE_FLOW_ERROR_TYPE_ITEM,
> -					item,
> -					"Not support range");
> +					   RTE_FLOW_ERROR_TYPE_ITEM,
> +					   item,
> +					   "Not support range");
>  			return -rte_errno;
>  		}
>  		item_type = item->type;
> 
> +		input_set = (tunnel_type && is_outer) ?
> +			    &outer_input_set :
> +			    &inner_input_set;
> +
> +		if (l3 == RTE_FLOW_ITEM_TYPE_IPV4)
> +			p_v4 = (tunnel_type && is_outer) ?
> +			       &filter->input.ip_outer.v4 :
> +			       &filter->input.ip.v4;
> +		if (l3 == RTE_FLOW_ITEM_TYPE_IPV6)
> +			p_v6 = (tunnel_type && is_outer) ?
> +			       &filter->input.ip_outer.v6 :
> +			       &filter->input.ip.v6;
> +
[Cao, Yahui] 
Why do you put p_v4 value assignment out of switch case RTE_FLOW_ITEM_TYPE_IPV4?
Why do you put p_v6 value assignment out of switch case RTE_FLOW_ITEM_TYPE_IPV6?

>  		switch (item_type) {
>  		case RTE_FLOW_ITEM_TYPE_ETH:
> +			flow_type = ICE_FLTR_PTYPE_NON_IP_L2;
>  			eth_spec = item->spec;
>  			eth_mask = item->mask;
> -			next_type = (item + 1)->type;
> 
> -			if (eth_spec && eth_mask) {
> -				if (!rte_is_zero_ether_addr(&eth_mask->dst)) {
> -					input_set |= ICE_INSET_DMAC;
> -					rte_memcpy(&filter->input.ext_data.dst_mac,
> -						   &eth_spec->dst,
> -						   RTE_ETHER_ADDR_LEN);
> -				}
> +			if (!(eth_spec && eth_mask))
> +				break;
> 
> -				if (!rte_is_zero_ether_addr(&eth_mask->src)) {
> -					input_set |= ICE_INSET_SMAC;
> -					rte_memcpy(&filter->input.ext_data.src_mac,
> -						   &eth_spec->src,
> -						   RTE_ETHER_ADDR_LEN);
> -				}
> +			*input_set |= is_outer ? ICE_PROT_MAC_OUTER : ICE_PROT_MAC_INNER;
[Cao, Yahui] 
ICE_PROT_XXX is internally used. You should use ICE_INSET_XXX version.
The same comment applies for similar case elsewhere.
> +			if (!rte_is_zero_ether_addr(&eth_mask->dst))
> +				*input_set |= ICE_DMAC;
[Cao, Yahui] 
You should not use ICE_DMAC here. You should use ICE_INSET_XXX version.
The same comment applies for similar case elsewhere.
> +			if (!rte_is_zero_ether_addr(&eth_mask->src))
> +				*input_set |= ICE_SMAC;
> 
> -				/* Ignore this field except for ICE_FLTR_PTYPE_NON_IP_L2 */
> -				if (eth_mask->type == RTE_BE16(0xffff) &&
> -				    next_type == RTE_FLOW_ITEM_TYPE_END) {
> -					input_set |= ICE_INSET_ETHERTYPE;
> -					ether_type = rte_be_to_cpu_16(eth_spec->type);
> -
> -					if (ether_type == RTE_ETHER_TYPE_IPV4 ||
> -					    ether_type == RTE_ETHER_TYPE_IPV6) {
> -						rte_flow_error_set(error, EINVAL,
> -								   RTE_FLOW_ERROR_TYPE_ITEM,
> -								   item,
> -								   "Unsupported ether_type.");
> -						return -rte_errno;
> -					}
> -
> -					rte_memcpy(&filter->input.ext_data.ether_type,
....
>  }
> --
> 2.25.1


  reply	other threads:[~2020-11-17 15:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17  8:45 [dpdk-dev] [PATCH v1] net/ice: refactor flow pattern parser Zhirun Yan
2020-11-17 15:31 ` Cao, Yahui [this message]
2020-11-18  3:15   ` Yan, Zhirun
2020-11-18  4:16     ` Cao, Yahui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=567972babaca49939efeebe98859eb50@intel.com \
    --to=yahui.cao@intel.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@intel.com \
    --cc=simei.su@intel.com \
    --cc=xiao.w.wang@intel.com \
    --cc=zhirun.yan@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.