From: "Yan, Zhirun" <zhirun.yan@intel.com>
To: "Cao, Yahui" <yahui.cao@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: [dpdk-dev] [PATCH v1] net/ice: refactor flow pattern parser
Date: Wed, 18 Nov 2020 03:15:24 +0000 [thread overview]
Message-ID: <3cb3569f17574168accda2bd6cdde6a1@intel.com> (raw)
In-Reply-To: <567972babaca49939efeebe98859eb50@intel.com>
* 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(ð_mask->dst)) {
> > - input_set |= ICE_INSET_DMAC;
> > - rte_memcpy(&filter->input.ext_data.dst_mac,
> > - ð_spec->dst,
> > - RTE_ETHER_ADDR_LEN);
> > - }
> > + if (!(eth_spec && eth_mask))
> > + break;
> >
> > - if (!rte_is_zero_ether_addr(ð_mask->src)) {
> > - input_set |= ICE_INSET_SMAC;
> > - rte_memcpy(&filter->input.ext_data.src_mac,
> > - ð_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.
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.
> > + if (!rte_is_zero_ether_addr(ð_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(ð_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
next prev parent reply other threads:[~2020-11-18 3:15 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 [this message]
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=3cb3569f17574168accda2bd6cdde6a1@intel.com \
--to=zhirun.yan@intel.com \
--cc=dev@dpdk.org \
--cc=qi.z.zhang@intel.com \
--cc=simei.su@intel.com \
--cc=xiao.w.wang@intel.com \
--cc=yahui.cao@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.