From: Jeff Guo <jia.guo@intel.com>
To: jingjing.wu@intel.com, qi.z.zhang@intel.com, beilei.xing@intel.com
Cc: dev@dpdk.org, jia.guo@intel.com
Subject: [dpdk-dev] [PATCH v4] net/iavf: support gtpu outer and inner co-exist
Date: Fri, 18 Sep 2020 13:46:56 +0800 [thread overview]
Message-ID: <20200918054656.94560-1-jia.guo@intel.com> (raw)
In-Reply-To: <20200909082031.28299-1-jia.guo@intel.com>
Although currently only the gtpu inner hash be enabled while not the
gtpu outer hash, but the outer protocol still needed to co-exist with
inner protocol when configure the gtpu inner hash rule, that would
allow the gtpu innner hash support for the different outer protocols.
Signed-off-by: Jeff Guo <jia.guo@intel.com>
---
v4->v3:
refine the header set
---
drivers/net/iavf/iavf_hash.c | 53 ++++++++++++++++++++++++++----------
1 file changed, 39 insertions(+), 14 deletions(-)
diff --git a/drivers/net/iavf/iavf_hash.c b/drivers/net/iavf/iavf_hash.c
index 3152218dc..34c425cdb 100644
--- a/drivers/net/iavf/iavf_hash.c
+++ b/drivers/net/iavf/iavf_hash.c
@@ -28,12 +28,17 @@
#define IAVF_PHINT_GTPU_EH BIT_ULL(1)
#define IAVF_PHINT_GTPU_EH_DWN BIT_ULL(2)
#define IAVF_PHINT_GTPU_EH_UP BIT_ULL(3)
+#define IAVF_PHINT_OUTER_IPV4 BIT_ULL(4)
+#define IAVF_PHINT_OUTER_IPV6 BIT_ULL(5)
#define IAVF_PHINT_GTPU_MSK (IAVF_PHINT_GTPU | \
IAVF_PHINT_GTPU_EH | \
IAVF_PHINT_GTPU_EH_DWN | \
IAVF_PHINT_GTPU_EH_UP)
+#define IAVF_PHINT_LAYERS_MSK (IAVF_PHINT_OUTER_IPV4 | \
+ IAVF_PHINT_OUTER_IPV6)
+
#define IAVF_GTPU_EH_DWNLINK 0
#define IAVF_GTPU_EH_UPLINK 1
@@ -499,8 +504,7 @@ iavf_hash_init(struct iavf_adapter *ad)
}
static int
-iavf_hash_parse_pattern(struct iavf_pattern_match_item *pattern_match_item,
- const struct rte_flow_item pattern[], uint64_t *phint,
+iavf_hash_parse_pattern(const struct rte_flow_item pattern[], uint64_t *phint,
struct rte_flow_error *error)
{
const struct rte_flow_item *item = pattern;
@@ -515,6 +519,14 @@ iavf_hash_parse_pattern(struct iavf_pattern_match_item *pattern_match_item,
}
switch (item->type) {
+ case RTE_FLOW_ITEM_TYPE_IPV4:
+ if (!(*phint & IAVF_PHINT_GTPU_MSK))
+ *phint |= IAVF_PHINT_OUTER_IPV4;
+ break;
+ case RTE_FLOW_ITEM_TYPE_IPV6:
+ if (!(*phint & IAVF_PHINT_GTPU_MSK))
+ *phint |= IAVF_PHINT_OUTER_IPV6;
+ break;
case RTE_FLOW_ITEM_TYPE_GTPU:
*phint |= IAVF_PHINT_GTPU;
break;
@@ -533,9 +545,6 @@ iavf_hash_parse_pattern(struct iavf_pattern_match_item *pattern_match_item,
}
}
- /* update and restore pattern hint */
- *phint |= *(uint64_t *)(pattern_match_item->meta);
-
return 0;
}
@@ -714,22 +723,39 @@ iavf_refine_proto_hdrs_by_pattern(struct virtchnl_proto_hdrs *proto_hdrs,
{
struct virtchnl_proto_hdr *hdr1;
struct virtchnl_proto_hdr *hdr2;
- int i;
+ int i, shift_count = 1;
if (!(phint & IAVF_PHINT_GTPU_MSK))
return;
+ if (phint & IAVF_PHINT_LAYERS_MSK)
+ shift_count++;
+
if (proto_hdrs->tunnel_level == TUNNEL_LEVEL_INNER) {
- /* shift headers 1 layer */
- for (i = proto_hdrs->count; i > 0; i--) {
+ /* shift headers layer */
+ for (i = proto_hdrs->count - 1 + shift_count;
+ i > shift_count - 1; i--) {
hdr1 = &proto_hdrs->proto_hdr[i];
- hdr2 = &proto_hdrs->proto_hdr[i - 1];
-
+ hdr2 = &proto_hdrs->proto_hdr[i - shift_count];
*hdr1 = *hdr2;
}
- /* adding gtpu header at layer 0 */
- hdr1 = &proto_hdrs->proto_hdr[0];
+ if (shift_count == 1) {
+ /* adding gtpu header at layer 0 */
+ hdr1 = &proto_hdrs->proto_hdr[0];
+ } else {
+ /* adding gtpu header and outer ip header */
+ hdr1 = &proto_hdrs->proto_hdr[1];
+ hdr2 = &proto_hdrs->proto_hdr[0];
+ hdr2->field_selector = 0;
+ proto_hdrs->count++;
+ proto_hdrs->tunnel_level = TUNNEL_LEVEL_OUTER;
+
+ if (phint & IAVF_PHINT_OUTER_IPV4)
+ VIRTCHNL_SET_PROTO_HDR_TYPE(hdr2, IPV4);
+ else if (phint & IAVF_PHINT_OUTER_IPV6)
+ VIRTCHNL_SET_PROTO_HDR_TYPE(hdr2, IPV6);
+ }
} else {
hdr1 = &proto_hdrs->proto_hdr[proto_hdrs->count];
}
@@ -908,8 +934,7 @@ iavf_hash_parse_pattern_action(__rte_unused struct iavf_adapter *ad,
goto error;
}
- ret = iavf_hash_parse_pattern(pattern_match_item, pattern, &phint,
- error);
+ ret = iavf_hash_parse_pattern(pattern, &phint, error);
if (ret)
goto error;
--
2.20.1
next prev parent reply other threads:[~2020-09-18 5:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 8:20 [dpdk-dev] [PATCH v1] " Jeff Guo
2020-09-16 4:18 ` [dpdk-dev] [PATCH v2] " Jeff Guo
2020-09-16 4:29 ` [dpdk-dev] [PATCH v3] " Jeff Guo
2020-09-18 5:46 ` Jeff Guo [this message]
2020-09-22 13:06 ` [dpdk-dev] [PATCH v4] " 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=20200918054656.94560-1-jia.guo@intel.com \
--to=jia.guo@intel.com \
--cc=beilei.xing@intel.com \
--cc=dev@dpdk.org \
--cc=jingjing.wu@intel.com \
--cc=qi.z.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).