[v3,1/3] net/iavf: support GTPU inner IPv4 for FDIR
Checks
Commit Message
Support GTPU_(EH)_IPV4 inner L3 and L4 fields matching for AVF FDIR.
+------------------------------+---------------------------------+
| Pattern | Input Set |
+------------------------------+---------------------------------+
| eth/ipv4/gtpu/ipv4 | inner: src/dst ip |
| eth/ipv4/gtpu/ipv4/udp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/ipv4/tcp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/eh/ipv4 | inner: src/dst ip |
| eth/ipv4/gtpu/eh/ipv4/udp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/eh/ipv4/tcp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/eh(0)/ipv4 | inner: src/dst ip |
| eth/ipv4/gtpu/eh(0)/ipv4/udp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/eh(0)/ipv4/tcp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/eh(1)/ipv4 | inner: src/dst ip |
| eth/ipv4/gtpu/eh(1)/ipv4/udp | inner: src/dst ip, src/dst port |
| eth/ipv4/gtpu/eh(1)/ipv4/tcp | inner: src/dst ip, src/dst port |
+------------------------------+---------------------------------+
Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
---
drivers/net/iavf/iavf_fdir.c | 37 ++++++++++++++++++++++++++++
drivers/net/iavf/iavf_generic_flow.h | 21 ++++++++++++++++
2 files changed, 58 insertions(+)
Comments
Hi,
I've found out the pretty useful experimental brand new flow ageing API
implemented in the mlx5 PMD.
I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED),
RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously offloaded.
The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are
5.1-2.5.8.0.
I eventually don't see the usefulness of the callback since it's
actually triggered indirectly by us(the DPDK application) when calling
rte_flow_get_aged_flows(). If we don't call it, the callback is called
only once.
And, calling rte_flow_get_aged_flows() from the callback won't trigger
it next time(MLX5_AGE_TRIGGER is reset after the callback call)
Furthermore, I don't see the point of computing ageing flows in
mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called.
So far, I can handle the flow ageing from the same thread as the one
which is handling the flow direction(rte_flow), it even avoid threads
synchronization. But, in the future, I may need to be noticed as soon as
possible of a single flow ageing, and thus handle this flow logic from
the ageing callback.
I may misunderstand the whole ageing API... Thanks a lot for any
clarification.
Sorry for the below topic confusion(in-reply-to).
On 3/29/21 9:50 AM, David Bouyeure wrote:
> Hi,
>
>
> I've found out the pretty useful experimental brand new flow ageing
> API implemented in the mlx5 PMD.
>
> I'm trying it (rte_eth_dev_callback_register(RTE_ETH_EVENT_FLOW_AGED),
> RTE_FLOW_ACTION_TYPE_AGE) to recover any flow that I previously
> offloaded.
>
> The DPDK version is 20.08 and Mellanox(Connect-X6) OFED drivers are
> 5.1-2.5.8.0.
>
> I eventually don't see the usefulness of the callback since it's
> actually triggered indirectly by us(the DPDK application) when calling
> rte_flow_get_aged_flows(). If we don't call it, the callback is called
> only once.
>
> And, calling rte_flow_get_aged_flows() from the callback won't trigger
> it next time(MLX5_AGE_TRIGGER is reset after the callback call)
>
> Furthermore, I don't see the point of computing ageing flows in
> mlx5_fow.c::mlx5_flow_aging_check() if the client callback isn't called.
>
> So far, I can handle the flow ageing from the same thread as the one
> which is handling the flow direction(rte_flow), it even avoid threads
> synchronization. But, in the future, I may need to be noticed as soon
> as possible of a single flow ageing, and thus handle this flow logic
> from the ageing callback.
>
>
> I may misunderstand the whole ageing API... Thanks a lot for any
> clarification.
>
On 3/26/2021 2:29 PM, Junfeng Guo wrote:
> Support GTPU_(EH)_IPV4 inner L3 and L4 fields matching for AVF FDIR.
>
> +------------------------------+---------------------------------+
> | Pattern | Input Set |
> +------------------------------+---------------------------------+
> | eth/ipv4/gtpu/ipv4 | inner: src/dst ip |
> | eth/ipv4/gtpu/ipv4/udp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/ipv4/tcp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/eh/ipv4 | inner: src/dst ip |
> | eth/ipv4/gtpu/eh/ipv4/udp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/eh/ipv4/tcp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/eh(0)/ipv4 | inner: src/dst ip |
> | eth/ipv4/gtpu/eh(0)/ipv4/udp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/eh(0)/ipv4/tcp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/eh(1)/ipv4 | inner: src/dst ip |
> | eth/ipv4/gtpu/eh(1)/ipv4/udp | inner: src/dst ip, src/dst port |
> | eth/ipv4/gtpu/eh(1)/ipv4/tcp | inner: src/dst ip, src/dst port |
> +------------------------------+---------------------------------+
>
> Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
<...>
> @@ -121,7 +134,13 @@ static struct iavf_pattern_match_item iavf_fdir_pattern[] = {
> {iavf_pattern_eth_ipv6_tcp, IAVF_FDIR_INSET_ETH_IPV6_TCP, IAVF_INSET_NONE},
> {iavf_pattern_eth_ipv6_sctp, IAVF_FDIR_INSET_ETH_IPV6_SCTP, IAVF_INSET_NONE},
> {iavf_pattern_eth_ipv4_gtpu, IAVF_FDIR_INSET_IPV4_GTPU, IAVF_INSET_NONE},
> + {iavf_pattern_eth_ipv4_gtpu_ipv4, IAVF_FDIR_INSET_GTPU_IPV4, IAVF_INSET_NONE},
> + {iavf_pattern_eth_ipv4_gtpu_ipv4_udp, IAVF_FDIR_INSET_GTPU_IPV4_UDP, IAVF_INSET_NONE},
> + {iavf_pattern_eth_ipv4_gtpu_ipv4_tcp, IAVF_FDIR_INSET_GTPU_IPV4_TCP, IAVF_INSET_NONE},
> {iavf_pattern_eth_ipv4_gtpu_eh, IAVF_FDIR_INSET_IPV4_GTPU_EH, IAVF_INSET_NONE},
> + {iavf_pattern_eth_ipv4_gtpu_eh_ipv4, IAVF_FDIR_INSET_GTPU_IPV4, IAVF_INSET_NONE},
> + {iavf_pattern_eth_ipv4_gtpu_eh_ipv4_udp,IAVF_FDIR_INSET_GTPU_IPV4_UDP, IAVF_INSET_NONE},
> + {iavf_pattern_eth_ipv4_gtpu_eh_ipv4_tcp,IAVF_FDIR_INSET_GTPU_IPV4_TCP, IAVF_INSET_NONE},
Syntax updated to fix checkpatch warning in next-net, space added after ',' &
addtional tab removed before third field.
Hi everybody,
I've implemented some flows offloading through rte_flow, and I'm just
finding out that my GTPC packets aren't handled the same way as my GTPU
ones by a Mellanox Connect-X6(FLEX_PARSER_PROFILE_ENABLE==3).
In others words, the GTP rules that I set are ignoring GTPC packets. The
DPDK api doc doesn't say anything about any GTP-C/GTP-U distinction as
far as I know, only that there's no way to set some filter against a
GTPv2(GTP-C) header.
There's a reference to RTE_GTPU_UDP_PORT in
dpdk.20.11.2/drivers/net/mlx5/mlx5_flow_dv.c::flow_dv_translate_item_gtp(),
and none to RTE_GTPC_UDP_PORT.
Do you confirm that mlx5 rte_flow implementation is definitely ignoring
GTPC packets? And, if so, for which reason?
Thanks a lot.
Regards.
@@ -75,6 +75,19 @@
IAVF_INSET_IPV4_SRC | IAVF_INSET_IPV4_DST | \
IAVF_INSET_GTPU_TEID)
+#define IAVF_FDIR_INSET_GTPU_IPV4 (\
+ IAVF_INSET_TUN_IPV4_SRC | IAVF_INSET_TUN_IPV4_DST | \
+ IAVF_INSET_TUN_IPV4_PROTO | IAVF_INSET_TUN_IPV4_TOS | \
+ IAVF_INSET_TUN_IPV4_TTL)
+
+#define IAVF_FDIR_INSET_GTPU_IPV4_UDP (\
+ IAVF_FDIR_INSET_GTPU_IPV4 | \
+ IAVF_INSET_TUN_UDP_SRC_PORT | IAVF_INSET_TUN_UDP_DST_PORT)
+
+#define IAVF_FDIR_INSET_GTPU_IPV4_TCP (\
+ IAVF_FDIR_INSET_GTPU_IPV4 | \
+ IAVF_INSET_TUN_TCP_SRC_PORT | IAVF_INSET_TUN_TCP_DST_PORT)
+
#define IAVF_FDIR_INSET_IPV4_GTPU_EH (\
IAVF_INSET_IPV4_SRC | IAVF_INSET_IPV4_DST | \
IAVF_INSET_GTPU_TEID | IAVF_INSET_GTPU_QFI)
@@ -121,7 +134,13 @@ static struct iavf_pattern_match_item iavf_fdir_pattern[] = {
{iavf_pattern_eth_ipv6_tcp, IAVF_FDIR_INSET_ETH_IPV6_TCP, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6_sctp, IAVF_FDIR_INSET_ETH_IPV6_SCTP, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv4_gtpu, IAVF_FDIR_INSET_IPV4_GTPU, IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv4_gtpu_ipv4, IAVF_FDIR_INSET_GTPU_IPV4, IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv4_gtpu_ipv4_udp, IAVF_FDIR_INSET_GTPU_IPV4_UDP, IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv4_gtpu_ipv4_tcp, IAVF_FDIR_INSET_GTPU_IPV4_TCP, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv4_gtpu_eh, IAVF_FDIR_INSET_IPV4_GTPU_EH, IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv4_gtpu_eh_ipv4, IAVF_FDIR_INSET_GTPU_IPV4, IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv4_gtpu_eh_ipv4_udp,IAVF_FDIR_INSET_GTPU_IPV4_UDP, IAVF_INSET_NONE},
+ {iavf_pattern_eth_ipv4_gtpu_eh_ipv4_tcp,IAVF_FDIR_INSET_GTPU_IPV4_TCP, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6_gtpu, IAVF_FDIR_INSET_IPV6_GTPU, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv6_gtpu_eh, IAVF_FDIR_INSET_IPV6_GTPU_EH, IAVF_INSET_NONE},
{iavf_pattern_eth_ipv4_l2tpv3, IAVF_FDIR_INSET_L2TPV3OIP, IAVF_INSET_NONE},
@@ -534,6 +553,7 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter *ad,
enum rte_flow_item_type next_type;
uint16_t ether_type;
+ u8 tun_inner = 0;
int layer = 0;
struct virtchnl_proto_hdr *hdr;
@@ -650,6 +670,11 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter *ad,
VIRTCHNL_ADD_PROTO_HDR_FIELD_BIT(hdr, IPV4, DST);
}
+ if (tun_inner) {
+ input_set &= ~IAVF_PROT_IPV4_OUTER;
+ input_set |= IAVF_PROT_IPV4_INNER;
+ }
+
rte_memcpy(hdr->buffer,
&ipv4_spec->hdr,
sizeof(ipv4_spec->hdr));
@@ -736,6 +761,11 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter *ad,
VIRTCHNL_ADD_PROTO_HDR_FIELD_BIT(hdr, UDP, DST_PORT);
}
+ if (tun_inner) {
+ input_set &= ~IAVF_PROT_UDP_OUTER;
+ input_set |= IAVF_PROT_UDP_INNER;
+ }
+
if (l3 == RTE_FLOW_ITEM_TYPE_IPV4)
rte_memcpy(hdr->buffer,
&udp_spec->hdr,
@@ -780,6 +810,11 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter *ad,
VIRTCHNL_ADD_PROTO_HDR_FIELD_BIT(hdr, TCP, DST_PORT);
}
+ if (tun_inner) {
+ input_set &= ~IAVF_PROT_TCP_OUTER;
+ input_set |= IAVF_PROT_TCP_INNER;
+ }
+
if (l3 == RTE_FLOW_ITEM_TYPE_IPV4)
rte_memcpy(hdr->buffer,
&tcp_spec->hdr,
@@ -858,6 +893,8 @@ iavf_fdir_parse_pattern(__rte_unused struct iavf_adapter *ad,
gtp_spec, sizeof(*gtp_spec));
}
+ tun_inner = 1;
+
filter->add_fltr.rule_cfg.proto_hdrs.count = ++layer;
break;
@@ -95,6 +95,17 @@
#define IAVF_INSET_IPV6_TC \
(IAVF_PROT_IPV6_OUTER | IAVF_IP_TOS)
+#define IAVF_INSET_TUN_IPV4_SRC \
+ (IAVF_PROT_IPV4_INNER | IAVF_IP_SRC)
+#define IAVF_INSET_TUN_IPV4_DST \
+ (IAVF_PROT_IPV4_INNER | IAVF_IP_DST)
+#define IAVF_INSET_TUN_IPV4_TOS \
+ (IAVF_PROT_IPV4_INNER | IAVF_IP_TOS)
+#define IAVF_INSET_TUN_IPV4_PROTO \
+ (IAVF_PROT_IPV4_INNER | IAVF_IP_PROTO)
+#define IAVF_INSET_TUN_IPV4_TTL \
+ (IAVF_PROT_IPV4_INNER | IAVF_IP_TTL)
+
#define IAVF_INSET_TCP_SRC_PORT \
(IAVF_PROT_TCP_OUTER | IAVF_SPORT)
#define IAVF_INSET_TCP_DST_PORT \
@@ -103,6 +114,16 @@
(IAVF_PROT_UDP_OUTER | IAVF_SPORT)
#define IAVF_INSET_UDP_DST_PORT \
(IAVF_PROT_UDP_OUTER | IAVF_DPORT)
+
+#define IAVF_INSET_TUN_TCP_SRC_PORT \
+ (IAVF_PROT_TCP_INNER | IAVF_SPORT)
+#define IAVF_INSET_TUN_TCP_DST_PORT \
+ (IAVF_PROT_TCP_INNER | IAVF_DPORT)
+#define IAVF_INSET_TUN_UDP_SRC_PORT \
+ (IAVF_PROT_UDP_INNER | IAVF_SPORT)
+#define IAVF_INSET_TUN_UDP_DST_PORT \
+ (IAVF_PROT_UDP_INNER | IAVF_DPORT)
+
#define IAVF_INSET_SCTP_SRC_PORT \
(IAVF_PROT_SCTP_OUTER | IAVF_SPORT)
#define IAVF_INSET_SCTP_DST_PORT \