All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cao, Yahui" <yahui.cao@intel.com>
To: "Yan, Zhirun" <zhirun.yan@intel.com>
Cc: "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: Wed, 18 Nov 2020 04:16:52 +0000	[thread overview]
Message-ID: <a87c1ffd527241f29bc139028ca45aa2@intel.com> (raw)
In-Reply-To: <3cb3569f17574168accda2bd6cdde6a1@intel.com>



> -----Original Message-----
> From: Yan, Zhirun <zhirun.yan@intel.com>
> Sent: Wednesday, November 18, 2020 11:15 AM
> To: Cao, Yahui <yahui.cao@intel.com>
> Cc: 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: [PATCH v1] net/ice: refactor flow pattern parser
> 
> * Cao, Yahui <yahui.cao@intel.com> [2020-11-17 23:31:40 +0800]:
> 
> > 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.
> >
> Thanks Yahui, will add more details. All changes in one function.
> 
> > >
> > > 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
> 
> Yes, will add GTP in v2.
> 
> > > +	}
> > > +
> > > +	/* 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?
> >
> 
> Yes, for RTE_FLOW_ITEM_TYPE_IPV4/6, p_v4/6 assigned in each case as you
> say.
> 
> But this is only for L4 layer parser. For L4 layer, the p_v4/6 is the shared pointer
> will be used after L3 loop.
> 
> 
> > >  		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.
> 
> How to distinguish internally used? ICE_PROT_XXX and ICE_INSET_XXX are
> defined in same file ice_generic_flow.h. And this kind of macro tries
> to introduce inner/outer bit to distinguish inner/outer, but actually
> it will mix field with its location. For FDIR, it seems not a good way.
> 
[Cao, Yahui] 
The distinguish rule is that only ICE_INSET_XXX is allowed to be used for input_set value. 
Otherwise, it may cause malfunction.


> There is much more cases for inner/outer and src/dst. So I try to
> use this line to set outer/inner bit first, and src/dst bit can be reused.
> 
[Cao, Yahui] 
It is a historical reason that input_set have both inner and outer field defined.
To not break the original design and also compatible with current design,
I suggest we can just deprecate the tunnel version field ICE_INSET_TUN_XXX and instead use the non-tunnel version like ICE_INSET_XXX.

For example, if you specify a vxlan filter rule with outter src ip and inner dst udp,
The value is like:
outer_input_set = ICE_INSET_IPV4_SRC
inner_input_set = ICE_INSET_UDP_DST_PORT

> > > +			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.
> 
> I guess this part should re-design if we want to use. So I prefer not to use
> it.
> 
> > > +			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
> >
> 
> --
> Best regards,
> Zhirun Yan

      reply	other threads:[~2020-11-18  4:17 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
2020-11-18  3:15   ` Yan, Zhirun
2020-11-18  4:16     ` Cao, Yahui [this message]

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=a87c1ffd527241f29bc139028ca45aa2@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.