[PATCH net-next 0/5] netfilter: add indr block setup in nf_flow_table_offload

[PATCH net-next 0/5] netfilter: add indr block setup in nf_flow_table_offload

[wenxu]

From: wenxu <wenxu@ucloud.cn>

This patch provide tunnel offload in nf_flow_table_offload based on
route lwtunnel. 
The first patch add TC_SETP_FT type in flow_indr_block_call.
The next two patches add support indr callback setup in flowtable offload.
The last two patches add tunnel match and action offload.

Test with mlx driver as following:

ip link add user1 type vrf table 1
ip l set user1 up 
ip l set dev mlx_pf0vf0 down
ip l set dev mlx_pf0vf0 master user1
ifconfig mlx_pf0vf0 10.0.0.1/24 up

ifconfig mlx_p0 172.168.152.75/24 up

ip l add dev tun1 type gretap key 1000
ip l set dev tun1 master user1
ifconfig tun1 10.0.1.1/24 up

ip r r 10.0.1.241 encap ip id 1000 dst 172.168.152.241 key dev tun1 table 1

nft add table firewall
nft add chain firewall zones { type filter hook prerouting priority - 300 \; }
nft add rule firewall zones counter ct zone set iif map { "tun1" : 1, "mlx_pf0vf0" : 1 }
nft add chain firewall rule-1000-ingress
nft add rule firewall rule-1000-ingress ct zone 1 ct state established,related counter accept
nft add rule firewall rule-1000-ingress ct zone 1 ct state invalid counter drop
nft add rule firewall rule-1000-ingress ct zone 1 tcp dport 5001 ct state new counter accept
nft add rule firewall rule-1000-ingress ct zone 1 udp dport 5001 ct state new counter accept
nft add rule firewall rule-1000-ingress ct zone 1 tcp dport 22 ct state new counter accept
nft add rule firewall rule-1000-ingress ct zone 1 ip protocol icmp ct state new counter accept
nft add rule firewall rule-1000-ingress counter drop
nft add chain firewall rules-all { type filter hook prerouting priority - 150 \; }
nft add rule firewall rules-all meta iifkind "vrf" counter accept
nft add rule firewall rules-all iif vmap { "tun1" : jump rule-1000-ingress }

nft add flowtable firewall fb1 { hook ingress priority 2 \; devices = { tun1, mlx_pf0vf0 } \; }
nft add chain firewall ftb-all {type filter hook forward priority 0 \; policy accept \; }
nft add rule firewall ftb-all ct zone 1 ip protocol tcp flow offload @fb1
nft add rule firewall ftb-all ct zone 1 ip protocol udp flow offload @fb1


wenxu (5):
  flow_offload: add TC_SETP_FT type in flow_indr_block_call
  netfilter: nf_flow_table_offload: refactor nf_flow_table_offload_setup
    to support indir setup
  netfilter: nf_flow_table_offload: add indr block setup support
  netfilter: nf_flow_table_offload: add tunnel match offload support
  netfilter: nf_flow_table_offload: add tunnel encap/decap action
    offload support

 include/net/flow_offload.h            |   3 +-
 net/core/flow_offload.c               |   6 +-
 net/netfilter/nf_flow_table_offload.c | 253 +++++++++++++++++++++++++++++++---
 net/netfilter/nf_tables_offload.c     |   2 +-
 net/sched/cls_api.c                   |   2 +-
 5 files changed, 243 insertions(+), 23 deletions(-)

-- 
1.8.3.1

[PATCH net-next 1/5] flow_offload: add TC_SETP_FT type in flow_indr_block_call

[wenxu]

From: wenxu <wenxu@ucloud.cn>

Add TC_SETP_FT type in flow_indr_block_call for supporting indr block call
in nf_flow_table_offload

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 include/net/flow_offload.h        | 3 ++-
 net/core/flow_offload.c           | 6 +++---
 net/netfilter/nf_tables_offload.c | 2 +-
 net/sched/cls_api.c               | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/net/flow_offload.h b/include/net/flow_offload.h
index c6f7bd2..5cf9396 100644
--- a/include/net/flow_offload.h
+++ b/include/net/flow_offload.h
@@ -410,6 +410,7 @@ void flow_indr_block_cb_unregister(struct net_device *dev,
 
 void flow_indr_block_call(struct net_device *dev,
 			  struct flow_block_offload *bo,
-			  enum flow_block_command command);
+			  enum flow_block_command command,
+			  enum tc_setup_type type);
 
 #endif /* _NET_FLOW_OFFLOAD_H */
diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c
index 45b6a59..c0d9223 100644
--- a/net/core/flow_offload.c
+++ b/net/core/flow_offload.c
@@ -483,7 +483,8 @@ void flow_indr_block_cb_unregister(struct net_device *dev,
 
 void flow_indr_block_call(struct net_device *dev,
 			  struct flow_block_offload *bo,
-			  enum flow_block_command command)
+			  enum flow_block_command command,
+			  enum tc_setup_type type)
 {
 	struct flow_indr_block_cb *indr_block_cb;
 	struct flow_indr_block_dev *indr_dev;
@@ -493,8 +494,7 @@ void flow_indr_block_call(struct net_device *dev,
 		return;
 
 	list_for_each_entry(indr_block_cb, &indr_dev->cb_list, list)
-		indr_block_cb->cb(dev, indr_block_cb->cb_priv, TC_SETUP_BLOCK,
-				  bo);
+		indr_block_cb->cb(dev, indr_block_cb->cb_priv, type, bo);
 }
 EXPORT_SYMBOL_GPL(flow_indr_block_call);
 
diff --git a/net/netfilter/nf_tables_offload.c b/net/netfilter/nf_tables_offload.c
index a9ea29a..a9e71b4 100644
--- a/net/netfilter/nf_tables_offload.c
+++ b/net/netfilter/nf_tables_offload.c
@@ -313,7 +313,7 @@ static int nft_indr_block_offload_cmd(struct nft_base_chain *chain,
 
 	nft_flow_block_offload_init(&bo, dev_net(dev), cmd, chain, &extack);
 
-	flow_indr_block_call(dev, &bo, cmd);
+	flow_indr_block_call(dev, &bo, cmd, TC_SETUP_BLOCK);
 
 	if (list_empty(&bo.cb_list))
 		return -EOPNOTSUPP;
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 6a0eaca..113be4d 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -714,7 +714,7 @@ static void tc_indr_block_call(struct tcf_block *block,
 	};
 	INIT_LIST_HEAD(&bo.cb_list);
 
-	flow_indr_block_call(dev, &bo, command);
+	flow_indr_block_call(dev, &bo, command, TC_SETUP_BLOCK);
 	tcf_block_setup(block, &bo);
 }
 
-- 
1.8.3.1

[PATCH net-next 2/5] netfilter: nf_flow_table_offload: refactor nf_flow_table_offload_setup to support indir setup

[wenxu]

From: wenxu <wenxu@ucloud.cn>

Refactor nf_flow_table_offload_setup to support indir setup in
the next patch

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 net/netfilter/nf_flow_table_offload.c | 54 ++++++++++++++++++++++++-----------
 1 file changed, 38 insertions(+), 16 deletions(-)

diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index de7a0d1..89eb1a5 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -808,26 +808,31 @@ static int nf_flow_table_block_setup(struct nf_flowtable *flowtable,
 	return err;
 }
 
-int nf_flow_table_offload_setup(struct nf_flowtable *flowtable,
-				struct net_device *dev,
-				enum flow_block_command cmd)
+static void nf_flow_table_block_offload_init(struct flow_block_offload *bo,
+					     struct net *net,
+					     enum flow_block_command cmd,
+					     struct nf_flowtable *flowtable,
+					     struct netlink_ext_ack *extack)
+{
+	memset(bo, 0, sizeof(*bo));
+	bo->net		= net;
+	bo->block	= &flowtable->flow_block;
+	bo->command	= cmd;
+	bo->binder_type	= FLOW_BLOCK_BINDER_TYPE_CLSACT_INGRESS;
+	bo->extack	= extack;
+	INIT_LIST_HEAD(&bo->cb_list);
+}
+
+static int nf_flow_table_offload_cmd(struct nf_flowtable *flowtable,
+				     struct net_device *dev,
+				     enum flow_block_command cmd)
 {
 	struct netlink_ext_ack extack = {};
-	struct flow_block_offload bo = {};
+	struct flow_block_offload bo;
 	int err;
 
-	if (!(flowtable->flags & NF_FLOWTABLE_HW_OFFLOAD))
-		return 0;
-
-	if (!dev->netdev_ops->ndo_setup_tc)
-		return -EOPNOTSUPP;
-
-	bo.net		= dev_net(dev);
-	bo.block	= &flowtable->flow_block;
-	bo.command	= cmd;
-	bo.binder_type	= FLOW_BLOCK_BINDER_TYPE_CLSACT_INGRESS;
-	bo.extack	= &extack;
-	INIT_LIST_HEAD(&bo.cb_list);
+	nf_flow_table_block_offload_init(&bo, dev_net(dev), cmd, flowtable,
+					 &extack);
 
 	err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_FT, &bo);
 	if (err < 0)
@@ -835,6 +840,23 @@ int nf_flow_table_offload_setup(struct nf_flowtable *flowtable,
 
 	return nf_flow_table_block_setup(flowtable, &bo, cmd);
 }
+
+int nf_flow_table_offload_setup(struct nf_flowtable *flowtable,
+				struct net_device *dev,
+				enum flow_block_command cmd)
+{
+	int err;
+
+	if (!(flowtable->flags & NF_FLOWTABLE_HW_OFFLOAD))
+		return 0;
+
+	if (dev->netdev_ops->ndo_setup_tc)
+		err = nf_flow_table_offload_cmd(flowtable, dev, cmd);
+	else
+		err = -EOPNOTSUPP;
+
+	return err;
+}
 EXPORT_SYMBOL_GPL(nf_flow_table_offload_setup);
 
 int nf_flow_table_offload_init(void)
-- 
1.8.3.1

[PATCH net-next 3/5] netfilter: nf_flow_table_offload: add indr block setup support

[wenxu]

From: wenxu <wenxu@ucloud.cn>

Nf flow table support indr-block setup. It makes flow table offload vlan
and tunnel device.

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 net/netfilter/nf_flow_table_offload.c | 89 ++++++++++++++++++++++++++++++++++-
 1 file changed, 88 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 89eb1a5..80d44a0 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -7,6 +7,7 @@
 #include <linux/tc_act/tc_csum.h>
 #include <net/flow_offload.h>
 #include <net/netfilter/nf_flow_table.h>
+#include <net/netfilter/nf_tables.h>
 #include <net/netfilter/nf_conntrack.h>
 #include <net/netfilter/nf_conntrack_core.h>
 #include <net/netfilter/nf_conntrack_tuple.h>
@@ -841,6 +842,24 @@ static int nf_flow_table_offload_cmd(struct nf_flowtable *flowtable,
 	return nf_flow_table_block_setup(flowtable, &bo, cmd);
 }
 
+static int nf_flow_table_indr_offload_cmd(struct nf_flowtable *flowtable,
+					  struct net_device *dev,
+					  enum flow_block_command cmd)
+{
+	struct netlink_ext_ack extack = {};
+	struct flow_block_offload bo;
+
+	nf_flow_table_block_offload_init(&bo, dev_net(dev), cmd, flowtable,
+					 &extack);
+
+	flow_indr_block_call(dev, &bo, cmd, TC_SETUP_FT);
+
+	if (list_empty(&bo.cb_list))
+		return -EOPNOTSUPP;
+
+	return nf_flow_table_block_setup(flowtable, &bo, cmd);
+}
+
 int nf_flow_table_offload_setup(struct nf_flowtable *flowtable,
 				struct net_device *dev,
 				enum flow_block_command cmd)
@@ -853,16 +872,82 @@ int nf_flow_table_offload_setup(struct nf_flowtable *flowtable,
 	if (dev->netdev_ops->ndo_setup_tc)
 		err = nf_flow_table_offload_cmd(flowtable, dev, cmd);
 	else
-		err = -EOPNOTSUPP;
+		err = nf_flow_table_indr_offload_cmd(flowtable, dev, cmd);
 
 	return err;
 }
 EXPORT_SYMBOL_GPL(nf_flow_table_offload_setup);
 
+static struct nf_flowtable *__nf_flow_table_offload_get(struct net_device *dev)
+{
+	struct nf_flowtable *n_flowtable;
+	struct nft_flowtable *flowtable;
+	struct net *net = dev_net(dev);
+	struct nft_table *table;
+	struct nft_hook *hook;
+
+	list_for_each_entry(table, &net->nft.tables, list) {
+		list_for_each_entry(flowtable, &table->flowtables, list) {
+			list_for_each_entry(hook, &flowtable->hook_list, list) {
+				if (hook->ops.dev != dev)
+					continue;
+
+				n_flowtable = &flowtable->data;
+				return n_flowtable;
+			}
+		}
+	}
+
+	return NULL;
+}
+
+static void nf_flow_table_indr_block_ing_cmd(struct net_device *dev,
+					     struct nf_flowtable *flowtable,
+					     flow_indr_block_bind_cb_t *cb,
+					     void *cb_priv,
+					     enum flow_block_command cmd)
+{
+	struct netlink_ext_ack extack = {};
+	struct flow_block_offload bo;
+
+	if (!flowtable)
+		return;
+
+	nf_flow_table_block_offload_init(&bo, dev_net(dev), cmd, flowtable,
+					 &extack);
+
+	cb(dev, cb_priv, TC_SETUP_FT, &bo);
+
+	nf_flow_table_block_setup(flowtable, &bo, cmd);
+}
+
+static void nf_flow_table_indr_block_cb(struct net_device *dev,
+					flow_indr_block_bind_cb_t *cb,
+					void *cb_priv,
+					enum flow_block_command cmd)
+{
+	struct net *net = dev_net(dev);
+	struct nf_flowtable *flowtable;
+
+	mutex_lock(&net->nft.commit_mutex);
+	flowtable = __nf_flow_table_offload_get(dev);
+	if (flowtable)
+		nf_flow_table_indr_block_ing_cmd(dev, flowtable, cb, cb_priv,
+						 cmd);
+	mutex_unlock(&net->nft.commit_mutex);
+}
+
+static struct flow_indr_block_entry block_ing_entry = {
+	.cb	= nf_flow_table_indr_block_cb,
+	.list	= LIST_HEAD_INIT(block_ing_entry.list),
+};
+
 int nf_flow_table_offload_init(void)
 {
 	INIT_WORK(&nf_flow_offload_work, flow_offload_work_handler);
 
+	flow_indr_add_block_cb(&block_ing_entry);
+
 	return 0;
 }
 
@@ -871,6 +956,8 @@ void nf_flow_table_offload_exit(void)
 	struct flow_offload_work *offload, *next;
 	LIST_HEAD(offload_pending_list);
 
+	flow_indr_del_block_cb(&block_ing_entry);
+
 	cancel_work_sync(&nf_flow_offload_work);
 
 	list_for_each_entry_safe(offload, next, &offload_pending_list, list) {
-- 
1.8.3.1

[PATCH net-next 4/5] netfilter: nf_flow_table_offload: add tunnel match offload support

[wenxu]

From: wenxu <wenxu@ucloud.cn>

This patch support both ipv4 and ipv6 tunnel_id, tunnel_src and
tunnel_dst match for flowtable offload

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 net/netfilter/nf_flow_table_offload.c | 67 +++++++++++++++++++++++++++++++++--
 1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 80d44a0..93ff2e6 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -26,11 +26,17 @@ struct flow_offload_work {
 
 struct nf_flow_key {
 	struct flow_dissector_key_control		control;
+	struct flow_dissector_key_control               enc_control;
 	struct flow_dissector_key_basic			basic;
 	union {
 		struct flow_dissector_key_ipv4_addrs	ipv4;
 		struct flow_dissector_key_ipv6_addrs	ipv6;
 	};
+	struct flow_dissector_key_keyid			enc_key_id;
+	union {
+		struct flow_dissector_key_ipv4_addrs	enc_ipv4;
+		struct flow_dissector_key_ipv6_addrs	enc_ipv6;
+	};
 	struct flow_dissector_key_tcp			tcp;
 	struct flow_dissector_key_ports			tp;
 } __aligned(BITS_PER_LONG / 8); /* Ensure that we can do comparisons as longs. */
@@ -50,11 +56,61 @@ struct nf_flow_rule {
 	(__match)->dissector.offset[__type] =		\
 		offsetof(struct nf_flow_key, __field)
 
+static void nf_flow_rule_lwt_match(struct nf_flow_match *match,
+				   struct ip_tunnel_info *tun_info)
+{
+	struct nf_flow_key *mask = &match->mask;
+	struct nf_flow_key *key = &match->key;
+	unsigned int enc_keys;
+
+	if (!tun_info || !(tun_info->mode & IP_TUNNEL_INFO_TX))
+		return;
+
+	NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_ENC_CONTROL, enc_control);
+	NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_ENC_KEYID, enc_key_id);
+	key->enc_key_id.keyid = tunnel_id_to_key32(tun_info->key.tun_id);
+	mask->enc_key_id.keyid = 0xffffffff;
+	enc_keys = BIT(FLOW_DISSECTOR_KEY_ENC_KEYID) |
+		   BIT(FLOW_DISSECTOR_KEY_ENC_CONTROL);
+
+	if (ip_tunnel_info_af(tun_info) == AF_INET) {
+		NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS,
+				  enc_ipv4);
+		key->enc_ipv4.src = tun_info->key.u.ipv4.dst;
+		key->enc_ipv4.dst = tun_info->key.u.ipv4.src;
+		if (key->enc_ipv4.src)
+			mask->enc_ipv4.src = 0xffffffff;
+		if (key->enc_ipv4.dst)
+			mask->enc_ipv4.dst = 0xffffffff;
+		enc_keys |= BIT(FLOW_DISSECTOR_KEY_ENC_IPV4_ADDRS);
+		key->enc_control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
+	} else {
+		memcpy(&key->enc_ipv6.src, &tun_info->key.u.ipv6.dst,
+		       sizeof(struct in6_addr));
+		memcpy(&key->enc_ipv6.dst, &tun_info->key.u.ipv6.src,
+		       sizeof(struct in6_addr));
+		if (memcmp(&key->enc_ipv6.src, &in6addr_any,
+			   sizeof(struct in6_addr)))
+			memset(&key->enc_ipv6.src, 0xff,
+			       sizeof(struct in6_addr));
+		if (memcmp(&key->enc_ipv6.dst, &in6addr_any,
+			   sizeof(struct in6_addr)))
+			memset(&key->enc_ipv6.dst, 0xff,
+			       sizeof(struct in6_addr));
+		enc_keys |= BIT(FLOW_DISSECTOR_KEY_ENC_IPV6_ADDRS);
+		key->enc_control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
+	}
+
+	match->dissector.used_keys |= enc_keys;
+}
+
 static int nf_flow_rule_match(struct nf_flow_match *match,
-			      const struct flow_offload_tuple *tuple)
+			      const struct flow_offload_tuple *tuple,
+			      struct dst_entry *other_dst)
 {
 	struct nf_flow_key *mask = &match->mask;
 	struct nf_flow_key *key = &match->key;
+	struct ip_tunnel_info *tun_info;
 
 	NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_CONTROL, control);
 	NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_BASIC, basic);
@@ -63,6 +119,11 @@ static int nf_flow_rule_match(struct nf_flow_match *match,
 	NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_TCP, tcp);
 	NF_FLOW_DISSECTOR(match, FLOW_DISSECTOR_KEY_PORTS, tp);
 
+	if (other_dst->lwtstate) {
+		tun_info = lwt_tun_info(other_dst->lwtstate);
+		nf_flow_rule_lwt_match(match, tun_info);
+	}
+
 	switch (tuple->l3proto) {
 	case AF_INET:
 		key->control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
@@ -475,6 +536,7 @@ int nf_flow_rule_route_ipv6(struct net *net, const struct flow_offload *flow,
 	const struct flow_offload *flow = offload->flow;
 	const struct flow_offload_tuple *tuple;
 	struct nf_flow_rule *flow_rule;
+	struct dst_entry *other_dst;
 	int err = -ENOMEM;
 
 	flow_rule = kzalloc(sizeof(*flow_rule), GFP_KERNEL);
@@ -490,7 +552,8 @@ int nf_flow_rule_route_ipv6(struct net *net, const struct flow_offload *flow,
 	flow_rule->rule->match.key = &flow_rule->match.key;
 
 	tuple = &flow->tuplehash[dir].tuple;
-	err = nf_flow_rule_match(&flow_rule->match, tuple);
+	other_dst = flow->tuplehash[!dir].tuple.dst_cache;
+	err = nf_flow_rule_match(&flow_rule->match, tuple, other_dst);
 	if (err < 0)
 		goto err_flow_match;
 
-- 
1.8.3.1

[PATCH net-next 5/5] netfilter: nf_flow_table_offload: add tunnel encap/decap action offload support

[wenxu]

From: wenxu <wenxu@ucloud.cn>

This patch add tunnel encap decap action offload in the flowtable
offload.

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 net/netfilter/nf_flow_table_offload.c | 47 +++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 93ff2e6..5fcb4bc 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -476,6 +476,45 @@ static void flow_offload_redirect(const struct flow_offload *flow,
 	dev_hold(rt->dst.dev);
 }
 
+static void flow_offload_encap_tunnel(const struct flow_offload *flow,
+				      enum flow_offload_tuple_dir dir,
+				      struct nf_flow_rule *flow_rule)
+{
+	struct flow_action_entry *entry;
+	struct dst_entry *dst;
+
+	dst = flow->tuplehash[dir].tuple.dst_cache;
+	if (dst->lwtstate) {
+		struct ip_tunnel_info *tun_info;
+
+		tun_info = lwt_tun_info(dst->lwtstate);
+		if (tun_info && (tun_info->mode & IP_TUNNEL_INFO_TX)) {
+			entry = flow_action_entry_next(flow_rule);
+			entry->id = FLOW_ACTION_TUNNEL_ENCAP;
+			entry->tunnel = tun_info;
+		}
+	}
+}
+
+static void flow_offload_decap_tunnel(const struct flow_offload *flow,
+				      enum flow_offload_tuple_dir dir,
+				      struct nf_flow_rule *flow_rule)
+{
+	struct flow_action_entry *entry;
+	struct dst_entry *dst;
+
+	dst = flow->tuplehash[!dir].tuple.dst_cache;
+	if (dst->lwtstate) {
+		struct ip_tunnel_info *tun_info;
+
+		tun_info = lwt_tun_info(dst->lwtstate);
+		if (tun_info && (tun_info->mode & IP_TUNNEL_INFO_TX)) {
+			entry = flow_action_entry_next(flow_rule);
+			entry->id = FLOW_ACTION_TUNNEL_DECAP;
+		}
+	}
+}
+
 int nf_flow_rule_route_ipv4(struct net *net, const struct flow_offload *flow,
 			    enum flow_offload_tuple_dir dir,
 			    struct nf_flow_rule *flow_rule)
@@ -496,6 +535,10 @@ int nf_flow_rule_route_ipv4(struct net *net, const struct flow_offload *flow,
 	    flow->flags & FLOW_OFFLOAD_DNAT)
 		flow_offload_ipv4_checksum(net, flow, flow_rule);
 
+	flow_offload_decap_tunnel(flow, dir, flow_rule);
+
+	flow_offload_encap_tunnel(flow, dir, flow_rule);
+
 	flow_offload_redirect(flow, dir, flow_rule);
 
 	return 0;
@@ -519,6 +562,10 @@ int nf_flow_rule_route_ipv6(struct net *net, const struct flow_offload *flow,
 		flow_offload_port_dnat(net, flow, dir, flow_rule);
 	}
 
+	flow_offload_decap_tunnel(flow, dir, flow_rule);
+
+	flow_offload_encap_tunnel(flow, dir, flow_rule);
+
 	flow_offload_redirect(flow, dir, flow_rule);
 
 	return 0;
-- 
1.8.3.1

Re: [PATCH net-next 0/5] netfilter: add indr block setup in nf_flow_table_offload

[wenxu]

在 2019/12/25 17:48, wenxu@ucloud.cn 写道:
> From: wenxu <wenxu@ucloud.cn>
>
> This patch provide tunnel offload in nf_flow_table_offload based on
> route lwtunnel. 
> The first patch add TC_SETP_FT type in flow_indr_block_call.
> The next two patches add support indr callback setup in flowtable offload.
> The last two patches add tunnel match and action offload.

Hi  David,

This series modify the net/core/flow_offload.c and net/sched/cls_api.c files.

This series maybe be suit for net-next tree but not nf-next tree?


BR

wenxu

>
>
> wenxu (5):
>   flow_offload: add TC_SETP_FT type in flow_indr_block_call
>   netfilter: nf_flow_table_offload: refactor nf_flow_table_offload_setup
>     to support indir setup
>   netfilter: nf_flow_table_offload: add indr block setup support
>   netfilter: nf_flow_table_offload: add tunnel match offload support
>   netfilter: nf_flow_table_offload: add tunnel encap/decap action
>     offload support
>
>  include/net/flow_offload.h            |   3 +-
>  net/core/flow_offload.c               |   6 +-
>  net/netfilter/nf_flow_table_offload.c | 253 +++++++++++++++++++++++++++++++---
>  net/netfilter/nf_tables_offload.c     |   2 +-
>  net/sched/cls_api.c                   |   2 +-
>  5 files changed, 243 insertions(+), 23 deletions(-)
>

Re: [PATCH net-next 0/5] netfilter: add indr block setup in nf_flow_table_offload

[David Miller]

From: wenxu <wenxu@ucloud.cn>
Date: Thu, 26 Dec 2019 09:46:51 +0800

> 在 2019/12/25 17:48, wenxu@ucloud.cn 写道:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> This patch provide tunnel offload in nf_flow_table_offload based on
>> route lwtunnel. 
>> The first patch add TC_SETP_FT type in flow_indr_block_call.
>> The next two patches add support indr callback setup in flowtable offload.
>> The last two patches add tunnel match and action offload.
> 
> Hi  David,
> 
> This series modify the net/core/flow_offload.c and net/sched/cls_api.c files.
> 
> This series maybe be suit for net-next tree but not nf-next tree?

It's fine for nf-next, we'll just resolve any conflicts that show up.

Problem about gre tunnel route offload in mlxsw

[wenxu]

Hi mlxsw team,


I did a route test with gre tunnel and vrf.

This test under current net-next tree with following script:


ifconfig enp3s0np31 up
ip a a dev enp3s0np31 172.168.152.247/24

ip l add dev vrf11 type vrf table 11
ifconfig vrf11 up
ip l set dev enp3s0np11 master vrf11
ifconfig enp3s0np11 10.0.7.1/24 up
ip tunnel add name gre11 mode gre local 172.168.152.247 remote 172.168.152.73 key 11 tos inherit  ttl inherit
ip l set dev gre11 master vrf11
ifconfig gre11 10.0.2.1/24 up

ip l add dev vrf21 type vrf table 21
ifconfig vrf21 up
ip l set dev enp3s0np21 master vrf21
ifconfig enp3s0np21 10.0.7.1/24 up
ip tunnel add name gre21 mode gre local 172.168.152.247 remote 172.168.152.73 key 21 tos inherit  ttl inherit
ip l set dev gre21 master vrf21
ifconfig gre21 10.0.2.1/24 up


If there is only one tunnel. The route rule can be offloaded. But two tunnel only with different key can't be offloaded.

If I add a new address 172.168.152.248 for tunnel source and change the gre21 to

"ip tunnel add name gre21 mode gre local 172.168.152.248 remote 172.168.152.73 key 21 tos inherit  ttl inherit"

It's work.

So it means dispatch based on tunnel key is not supported ? It is a hardware limits or just software unsupported?


And if a replace the gre device to vxlan device,  the route can't be offloaded again only with one vxlan tunnel.

"ip l add dev vxlan11 type vxlan local 172.168.152.247 remote 172.168.152.73 id 11 noudpcsum tos inherit ttl inherit dstport 4789"

So currently the vxlan device can't work with routing?


BR

wenxu

Re: Problem about gre tunnel route offload in mlxsw

[Ido Schimmel]

On Thu, Dec 26, 2019 at 01:07:33PM +0800, wenxu wrote:
> Hi mlxsw team,
> 
> 
> I did a route test with gre tunnel and vrf.
> 
> This test under current net-next tree with following script:
> 
> 
> ifconfig enp3s0np31 up
> ip a a dev enp3s0np31 172.168.152.247/24
> 
> ip l add dev vrf11 type vrf table 11
> ifconfig vrf11 up
> ip l set dev enp3s0np11 master vrf11
> ifconfig enp3s0np11 10.0.7.1/24 up
> ip tunnel add name gre11 mode gre local 172.168.152.247 remote 172.168.152.73 key 11 tos inherit  ttl inherit
> ip l set dev gre11 master vrf11
> ifconfig gre11 10.0.2.1/24 up
> 
> ip l add dev vrf21 type vrf table 21
> ifconfig vrf21 up
> ip l set dev enp3s0np21 master vrf21
> ifconfig enp3s0np21 10.0.7.1/24 up
> ip tunnel add name gre21 mode gre local 172.168.152.247 remote 172.168.152.73 key 21 tos inherit  ttl inherit
> ip l set dev gre21 master vrf21
> ifconfig gre21 10.0.2.1/24 up
> 
> 
> If there is only one tunnel. The route rule can be offloaded. But two tunnel only with different key can't be offloaded.
> 
> If I add a new address 172.168.152.248 for tunnel source and change the gre21 to
> 
> "ip tunnel add name gre21 mode gre local 172.168.152.248 remote 172.168.152.73 key 21 tos inherit  ttl inherit"
> 
> It's work.
> 
> So it means dispatch based on tunnel key is not supported ?

Yes. See:
"No two tunnels that share underlay VRF shall share a local address
(i.e. dispatch based on tunnel key is not supported)"

https://github.com/Mellanox/mlxsw/wiki/L3-Tunneling#features-and-limitations

> It is a hardware limits or just software unsupported?

Software. In hardware you can perform decapsulation in the router or
using ACLs. mlxsw uses the former so the key is {tb_id, prefix}. With
ACLs it is possible to match on more attributes.

> 
> 
> And if a replace the gre device to vxlan device,  the route can't be offloaded again only with one vxlan tunnel.
> 
> "ip l add dev vxlan11 type vxlan local 172.168.152.247 remote 172.168.152.73 id 11 noudpcsum tos inherit ttl inherit dstport 4789"
> 
> So currently the vxlan device can't work with routing?

Yes. We don't perform VXLAN encapsulation in the router, only in bridge.
See:
https://github.com/Mellanox/mlxsw/wiki/Virtual-eXtensible-Local-Area-Network-%28VXLAN%29

> 
> 
> BR
> 
> wenxu
> 
> 
> 
> 
> 

Re: Problem about gre tunnel route offload in mlxsw

[wenxu]

On 12/26/2019 3:49 PM, Ido Schimmel wrote:
> On Thu, Dec 26, 2019 at 01:07:33PM +0800, wenxu wrote:
>> Hi mlxsw team,
>>
>>
>> I did a route test with gre tunnel and vrf.
>>
>> This test under current net-next tree with following script:
>>
>>
>> ifconfig enp3s0np31 up
>> ip a a dev enp3s0np31 172.168.152.247/24
>>
>> ip l add dev vrf11 type vrf table 11
>> ifconfig vrf11 up
>> ip l set dev enp3s0np11 master vrf11
>> ifconfig enp3s0np11 10.0.7.1/24 up
>> ip tunnel add name gre11 mode gre local 172.168.152.247 remote 172.168.152.73 key 11 tos inherit  ttl inherit
>> ip l set dev gre11 master vrf11
>> ifconfig gre11 10.0.2.1/24 up
>>
>> ip l add dev vrf21 type vrf table 21
>> ifconfig vrf21 up
>> ip l set dev enp3s0np21 master vrf21
>> ifconfig enp3s0np21 10.0.7.1/24 up
>> ip tunnel add name gre21 mode gre local 172.168.152.247 remote 172.168.152.73 key 21 tos inherit  ttl inherit
>> ip l set dev gre21 master vrf21
>> ifconfig gre21 10.0.2.1/24 up
>>
>>
>> If there is only one tunnel. The route rule can be offloaded. But two tunnel only with different key can't be offloaded.
>>
>> If I add a new address 172.168.152.248 for tunnel source and change the gre21 to
>>
>> "ip tunnel add name gre21 mode gre local 172.168.152.248 remote 172.168.152.73 key 21 tos inherit  ttl inherit"
>>
>> It's work.
>>
>> So it means dispatch based on tunnel key is not supported ?
> Yes. See:
> "No two tunnels that share underlay VRF shall share a local address
> (i.e. dispatch based on tunnel key is not supported)"
>
> https://github.com/Mellanox/mlxsw/wiki/L3-Tunneling#features-and-limitations
>
>> It is a hardware limits or just software unsupported?
> Software. In hardware you can perform decapsulation in the router or
> using ACLs. mlxsw uses the former so the key is {tb_id, prefix}. With
> ACLs it is possible to match on more attributes.
>
I find mlxsw use ACL through TC flower. But currently It does't support ecn_*_keys in the flower match?

Also it doesn't support the action "redirect to GRE Tunnel device"?

Re: Problem about gre tunnel route offload in mlxsw

[Ido Schimmel]

On Thu, Dec 26, 2019 at 04:22:48PM +0800, wenxu wrote:
> 
> On 12/26/2019 3:49 PM, Ido Schimmel wrote:
> > On Thu, Dec 26, 2019 at 01:07:33PM +0800, wenxu wrote:
> >> Hi mlxsw team,
> >>
> >>
> >> I did a route test with gre tunnel and vrf.
> >>
> >> This test under current net-next tree with following script:
> >>
> >>
> >> ifconfig enp3s0np31 up
> >> ip a a dev enp3s0np31 172.168.152.247/24
> >>
> >> ip l add dev vrf11 type vrf table 11
> >> ifconfig vrf11 up
> >> ip l set dev enp3s0np11 master vrf11
> >> ifconfig enp3s0np11 10.0.7.1/24 up
> >> ip tunnel add name gre11 mode gre local 172.168.152.247 remote 172.168.152.73 key 11 tos inherit  ttl inherit
> >> ip l set dev gre11 master vrf11
> >> ifconfig gre11 10.0.2.1/24 up
> >>
> >> ip l add dev vrf21 type vrf table 21
> >> ifconfig vrf21 up
> >> ip l set dev enp3s0np21 master vrf21
> >> ifconfig enp3s0np21 10.0.7.1/24 up
> >> ip tunnel add name gre21 mode gre local 172.168.152.247 remote 172.168.152.73 key 21 tos inherit  ttl inherit
> >> ip l set dev gre21 master vrf21
> >> ifconfig gre21 10.0.2.1/24 up
> >>
> >>
> >> If there is only one tunnel. The route rule can be offloaded. But two tunnel only with different key can't be offloaded.
> >>
> >> If I add a new address 172.168.152.248 for tunnel source and change the gre21 to
> >>
> >> "ip tunnel add name gre21 mode gre local 172.168.152.248 remote 172.168.152.73 key 21 tos inherit  ttl inherit"
> >>
> >> It's work.
> >>
> >> So it means dispatch based on tunnel key is not supported ?
> > Yes. See:
> > "No two tunnels that share underlay VRF shall share a local address
> > (i.e. dispatch based on tunnel key is not supported)"
> >
> > https://github.com/Mellanox/mlxsw/wiki/L3-Tunneling#features-and-limitations
> >
> >> It is a hardware limits or just software unsupported?
> > Software. In hardware you can perform decapsulation in the router or
> > using ACLs. mlxsw uses the former so the key is {tb_id, prefix}. With
> > ACLs it is possible to match on more attributes.
> >
> I find mlxsw use ACL through TC flower.

When I wrote that it is possible to use ACLs to perform the
decapsulation I meant that mlxsw will do that internally, instead of
using a local route with a decap action. Not that the user will do it.

> But currently It does't support ecn_*_keys in the flower match?

Yes.
https://github.com/Mellanox/mlxsw/wiki/ACLs#supported-keys

> 
> Also it doesn't support the action "redirect to GRE Tunnel device"?

Right. Only redirect to physical ports is currently supported.

>