All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Guo, Jia" <jia.guo@intel.com>
To: "Li, Xiaoyun" <xiaoyun.li@intel.com>,
	"orika@nvidia.com" <orika@nvidia.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	"Xing, Beilei" <beilei.xing@intel.com>,
	"Wu, Jingjing" <jingjing.wu@intel.com>
Cc: "Zhang, Yuying" <yuying.zhang@intel.com>,
	"Xu, Ting" <ting.xu@intel.com>,  "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v1 4/4] net/iavf: support FDIR for IP fragment packet
Date: Tue, 23 Mar 2021 00:58:19 +0000	[thread overview]
Message-ID: <dabc778d1a104a9ab708d7e933f9a97c@intel.com> (raw)
In-Reply-To: <DM4PR11MB55345C5CF290C172BF64972599689@DM4PR11MB5534.namprd11.prod.outlook.com>

Hi, xiaoyun

> -----Original Message-----
> From: Li, Xiaoyun <xiaoyun.li@intel.com>
> Sent: Friday, March 19, 2021 3:57 PM
> To: Guo, Jia <jia.guo@intel.com>; orika@nvidia.com; Zhang, Qi Z
> <qi.z.zhang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>
> Cc: Zhang, Yuying <yuying.zhang@intel.com>; Xu, Ting <ting.xu@intel.com>;
> dev@dpdk.org
> Subject: RE: [PATCH v1 4/4] net/iavf: support FDIR for IP fragment packet
> 
> Hi
> 
> > -----Original Message-----
> > From: Guo, Jia <jia.guo@intel.com>
> > Sent: Wednesday, March 17, 2021 11:12
> > To: orika@nvidia.com; Zhang, Qi Z <qi.z.zhang@intel.com>; Xing, Beilei
> > <beilei.xing@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>; Wu,
> > Jingjing <jingjing.wu@intel.com>
> > Cc: Zhang, Yuying <yuying.zhang@intel.com>; Xu, Ting
> > <ting.xu@intel.com>; dev@dpdk.org; Guo, Jia <jia.guo@intel.com>
> > Subject: [PATCH v1 4/4] net/iavf: support FDIR for IP fragment packet
> >
> > New FDIR parsing are added to handle the fragmented IPv4/IPv6 packet.
> >
> > Signed-off-by: Ting Xu <ting.xu@intel.com>
> > Signed-off-by: Jeff Guo <jia.guo@intel.com>
> > ---
> >  drivers/net/iavf/iavf_fdir.c         | 278 ++++++++++++++++++---------
> >  drivers/net/iavf/iavf_generic_flow.h |   5 +
> >  2 files changed, 190 insertions(+), 93 deletions(-)
> >
> > diff --git a/drivers/net/iavf/iavf_fdir.c
> > b/drivers/net/iavf/iavf_fdir.c index
> > e3f3b5f22a..348d423081 100644
> > --- a/drivers/net/iavf/iavf_fdir.c
> > +++ b/drivers/net/iavf/iavf_fdir.c
> > @@ -34,7 +34,7 @@
> <snip>
> >
> >  uint8_t  ipv6_addr_mask[16] = {
> >  0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, @@ -528,12
> > +534,6 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter
> > +*ad,
> >  };
> >
> >  for (item = pattern; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> > -if (item->last) {
> 
> You can't directly remove the check. If users use "last" for items like
> RTE_FLOW_ITEM_TYPE_ETH. The driver doesn't support that.
> 

Oh, that is like as you said. Specific enabling should be addressed.

> > -rte_flow_error_set(error, EINVAL,
> > -RTE_FLOW_ERROR_TYPE_ITEM, item,
> > -"Not support range");
> > -}
> > -
> >  item_type = item->type;
> >
> <snip>
> > +if (ipv4_mask->hdr.version_ihl ||
> > +    ipv4_mask->hdr.total_length ||
> > +    ipv4_mask->hdr.hdr_checksum) {
> > +rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ITEM,
> > +   item, "Invalid IPv4 mask.");
> > +return -rte_errno;
> > +}
> >
> > -rte_memcpy(hdr->buffer,
> > -&ipv4_spec->hdr,
> > -sizeof(ipv4_spec->hdr));
> 
> The ipv4_mask is checked. But what about ipv4_last?
> What if users set a rule which includes "last" for hdr.version_ihl? The code
> doesn't process that and not err return.
> You should block all situations in ipv4_last except for ipv4_last-
> >hdr.fragment_offset.
> 

Ok.

> <snip>
> > +
> > +if (ipv4_mask->hdr.packet_id == UINT16_MAX ||
> > +    ipv4_mask->hdr.fragment_offset == UINT16_MAX) {
> 
> And I don't understand your logic here.
> Only if ipv4_mask->hdr.fragment_offset and ipv4_mask->hdr.packet_id Are
> UINT16_MAX, you process this case. But what about other cases? Shouldn't
> those cases return err like not supported?
> And the mask for fragment_offset shouldn't be 0xffff (UINT16_MAX), it
> should be 0x3fff (RTE_IPV4_HDR_OFFSET_MASK |
> RTE_IPV4_HDR_MF_FLAG). Because only the last 14 bits matters. The other 2
> bits are reserved bit and DF bit, it doesn't matter if it's fragment packets or
> not.
> 

Em, there are definitely something not cover. The negotiate should be specific at device but not at avf.

> > +if (ipv4_last &&
> > +    ipv4_spec->hdr.packet_id == 0 &&
> > +    ipv4_last->hdr.packet_id == 0xffff)
> 
> And I don't understand this part too. I thought it's a fragment rule and non-
> fragment rule. Why is this related to packet_id? And what about
> fragment_offset spec and last?
> In ovs usercase, the rule for fragment packets is like flow create 0 ingress
> pattern eth / ipv4 src is xxx dst is xxx fragment_offset spec 0x8
> fragment_offset last 0x2000 fragment_offset mask 0x3fff / end actions
> queue index 1 / end
> 
> And the rule for non-fragment rule is like:
> flow create 0 ingress pattern eth / ipv4 src is xxx dst is xxx fragment_offset
> spec 0 fragment_offset mask 0x3fff / end actions queue index 1 / end or
> flow create 0 ingress pattern eth / ipv4 src is xxx dst is xxx fragment_offset
> mask 0x3fff / end actions queue index 1 / end
> 
> How can your codes here make sure the rules behave correctly?
> 

What i want is that use a dummy input set for the fragment packet. At lease, we have handle 5tuple/specific id/any packet id for Fragment packet, and for one-fragment packet, seems that no need to
use fragment_offset to identify it seem default is for ip other.  


> > +spec_all_pid = true;
> > +
> > +/* All IPv4 fragment packet has the same
> > + * ethertype, if the spec is for all invalid
> > + * packet id, set the ethertype into input set.
> > + */
> > +input_set |= spec_all_pid ?
> > +IAVF_INSET_ETHERTYPE :
> > +IAVF_INSET_IPV4_ID;
> > +
> > +if (spec_all_pid)
> > +
> > VIRTCHNL_ADD_PROTO_HDR_FIELD_BIT(hdr1,
> > +ETH, ETHERTYPE);
> > +else
> > +
> > VIRTCHNL_ADD_PROTO_HDR_FIELD_BIT(hdr,
> > +IPV4, PKID);
> >  }
> >
> > +rte_memcpy(hdr->buffer, &ipv4_spec->hdr,
> > +   sizeof(ipv4_spec->hdr));
> > +
> >  hdrs.count = ++layer;
> >  break;
> >
> 
> I'm not familiar with IPv6 fragment rule. So not review that part.
> 
> <snip>
> > --
> > 2.20.1
> 


  reply	other threads:[~2021-03-23  0:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17  3:12 [dpdk-dev] [PATCH v1 0/4] support flow for IP fragment in IAVF Jeff Guo
2021-03-17  3:12 ` [dpdk-dev] [PATCH v1 1/4] app/testpmd: add packet id for IP fragment Jeff Guo
2021-03-17  3:12 ` [dpdk-dev] [PATCH v1 2/4] common/iavf: add proto header " Jeff Guo
2021-03-17  3:12 ` [dpdk-dev] [PATCH v1 3/4] net/iavf: support RSS hash " Jeff Guo
2021-03-17  3:12 ` [dpdk-dev] [PATCH v1 4/4] net/iavf: support FDIR for IP fragment packet Jeff Guo
2021-03-19  7:57   ` Li, Xiaoyun
2021-03-23  0:58     ` Guo, Jia [this message]
2021-03-24 13:48 ` [dpdk-dev] [PATCH v2 0/4] support flow for IP fragment in IAVF Jeff Guo
2021-03-24 13:48   ` [dpdk-dev] [PATCH v2 1/4] app/testpmd: add packet id for IP fragment Jeff Guo
2021-03-24 13:48   ` [dpdk-dev] [PATCH v2 2/4] common/iavf: add proto header " Jeff Guo
2021-03-24 13:48   ` [dpdk-dev] [PATCH v2 3/4] net/iavf: support RSS hash " Jeff Guo
2021-03-24 13:48   ` [dpdk-dev] [PATCH v2 4/4] net/iavf: support FDIR for IP fragment packet Jeff Guo
2021-04-11  6:01   ` [dpdk-dev] [PATCH v3 1/4] app/testpmd: add packet id for IP fragment Jeff Guo
2021-04-11  6:01     ` [dpdk-dev] [PATCH v3 2/4] common/iavf: add proto header " Jeff Guo
2021-04-11  6:01     ` [dpdk-dev] [PATCH v3 3/4] net/iavf: support RSS hash " Jeff Guo
2021-04-11  6:01     ` [dpdk-dev] [PATCH v3 4/4] net/iavf: support FDIR for IP fragment packet Jeff Guo
2021-04-12  8:45       ` Xu, Ting
2021-04-13  1:57         ` Guo, Jia
2021-04-11  6:07   ` [dpdk-dev] [PATCH v3 0/3] support flow for IP fragment in ICE Jeff Guo
2021-04-11  6:59   ` [dpdk-dev] [PATCH v3 0/4] support flow for IP fragment in IAVF Jeff Guo
2021-04-11  6:59     ` [dpdk-dev] [PATCH v3 1/4] app/testpmd: add packet id for IP fragment Jeff Guo
2021-04-11  6:59     ` [dpdk-dev] [PATCH v3 2/4] common/iavf: add proto header " Jeff Guo
2021-04-11  6:59     ` [dpdk-dev] [PATCH v3 3/4] net/iavf: support RSS hash " Jeff Guo
2021-04-11  6:59     ` [dpdk-dev] [PATCH v3 4/4] net/iavf: support FDIR for IP fragment packet Jeff Guo
2021-04-13  8:10   ` [dpdk-dev] [PATCH v4 0/4] support flow for IP fragment in IAVF Jeff Guo
2021-04-13  8:10     ` [dpdk-dev] [PATCH v4 1/4] app/testpmd: add packet id for IP fragment Jeff Guo
2021-04-19  7:43       ` Jack Min
2021-04-19 15:40         ` Ferruh Yigit
2021-04-20  2:21           ` Jack Min
2021-04-19 15:37       ` Ferruh Yigit
2021-04-19 17:45       ` Ori Kam
2021-04-19 23:01         ` Ferruh Yigit
2021-04-13  8:10     ` [dpdk-dev] [PATCH v4 2/4] common/iavf: add proto header " Jeff Guo
2021-04-13  8:10     ` [dpdk-dev] [PATCH v4 3/4] net/iavf: support RSS hash " Jeff Guo
2021-04-13  8:10     ` [dpdk-dev] [PATCH v4 4/4] net/iavf: support FDIR for IP fragment packet Jeff Guo
2021-04-13  9:30     ` [dpdk-dev] [PATCH v4 0/4] support flow for IP fragment in IAVF Zhang, Qi Z

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=dabc778d1a104a9ab708d7e933f9a97c@intel.com \
    --to=jia.guo@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    --cc=orika@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=ting.xu@intel.com \
    --cc=xiaoyun.li@intel.com \
    --cc=yuying.zhang@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.