[PATCH net-next 1/5] net/mlx5e: Return -EOPNOTSUPP when modify header action zero

[PATCH net-next 1/5] net/mlx5e: Return -EOPNOTSUPP when modify header action zero

[xiangxia.m.yue]

From: Tonghao Zhang <xiangxia.m.yue@gmail.com>

When max modify header action is zero, we return -EOPNOTSUPP
directly. In this way, we can ignore wrong message info (e.g.
"mlx5: parsed 0 pedit actions, can't do more").

This happens when offloading pedit actions on mlx VFs.

For example:
$ tc filter add dev mlx_vfs parent ffff: protocol ip prio 1 \
	flower skip_sw dst_mac 00:10:56:fb:64:e8 \
	dst_ip 1.1.1.100 src_ip 1.1.1.200 \
	action pedit ex munge eth src set 00:10:56:b4:5d:20

Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index b38986e..c4359f1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2002,7 +2002,8 @@ static int offload_pedit_fields(struct pedit_headers_action *hdrs,
 static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
 				 struct pedit_headers_action *hdrs,
 				 int namespace,
-				 struct mlx5e_tc_flow_parse_attr *parse_attr)
+				 struct mlx5e_tc_flow_parse_attr *parse_attr,
+				 struct netlink_ext_ack *extack)
 {
 	int nkeys, action_size, max_actions;
 
@@ -2015,6 +2016,13 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
 	else /* namespace is MLX5_FLOW_NAMESPACE_KERNEL - NIC offloading */
 		max_actions = MLX5_CAP_FLOWTABLE_NIC_RX(priv->mdev, max_modify_header_actions);
 
+	if (!max_actions) {
+		NL_SET_ERR_MSG_MOD(extack,
+				   "don't support pedit actions, can't offload");
+		netdev_warn(priv->netdev, "don't support pedit actions, can't offload\n");
+		return -EOPNOTSUPP;
+	}
+
 	/* can get up to crazingly 16 HW actions in 32 bits pedit SW key */
 	max_actions = min(max_actions, nkeys * 16);
 
@@ -2072,7 +2080,8 @@ static int alloc_tc_pedit_action(struct mlx5e_priv *priv, int namespace,
 	u8 cmd;
 
 	if (!parse_attr->mod_hdr_actions) {
-		err = alloc_mod_hdr_actions(priv, hdrs, namespace, parse_attr);
+		err = alloc_mod_hdr_actions(priv, hdrs,
+					    namespace, parse_attr, extack);
 		if (err)
 			goto out_err;
 	}
-- 
1.8.3.1

[PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported

[xiangxia.m.yue]

From: Tonghao Zhang <xiangxia.m.yue@gmail.com>

If we try to offload decapsulation actions to VFs hw, we get the log [1].
It's not friendly, because the kind of net device is null, and we don't
know what '0' means.

[1] "mlx5_core 0000:05:01.2 vf_0: decapsulation offload is not supported for  net device (0)"

Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
index bdcc5e7..6911e0a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
@@ -620,8 +620,10 @@ int mlx5e_tc_tun_parse(struct net_device *filter_dev,
 						headers_c, headers_v);
 	} else {
 		netdev_warn(priv->netdev,
-			    "decapsulation offload is not supported for %s net device (%d)\n",
-			    mlx5e_netdev_kind(filter_dev), tunnel_type);
+			    "decapsulation offload is not supported for %s (kind: \"%s\")\n",
+			    netdev_name(filter_dev),
+			    mlx5e_netdev_kind(filter_dev));
+
 		return -EOPNOTSUPP;
 	}
 	return err;
-- 
1.8.3.1

[PATCH net-next 3/5] net/mlx5e: Remove 'parse_attr' argument in parse_tc_fdb_actions()

[xiangxia.m.yue]

From: Tonghao Zhang <xiangxia.m.yue@gmail.com>

This patch is a little improvement. Simplify the parse_tc_fdb_actions().

Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index c4359f1..bbe2374 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2476,13 +2476,13 @@ static int parse_tc_vlan_action(struct mlx5e_priv *priv,
 
 static int parse_tc_fdb_actions(struct mlx5e_priv *priv,
 				struct flow_action *flow_action,
-				struct mlx5e_tc_flow_parse_attr *parse_attr,
 				struct mlx5e_tc_flow *flow,
 				struct netlink_ext_ack *extack)
 {
 	struct pedit_headers_action hdrs[2] = {};
 	struct mlx5_eswitch *esw = priv->mdev->priv.eswitch;
 	struct mlx5_esw_flow_attr *attr = flow->esw_attr;
+	struct mlx5e_tc_flow_parse_attr *parse_attr = attr->parse_attr;
 	struct mlx5e_rep_priv *rpriv = priv->ppriv;
 	const struct ip_tunnel_info *info = NULL;
 	const struct flow_action_entry *act;
@@ -2797,7 +2797,7 @@ static bool is_peer_flow_needed(struct mlx5e_tc_flow *flow)
 	if (err)
 		goto err_free;
 
-	err = parse_tc_fdb_actions(priv, &rule->action, parse_attr, flow, extack);
+	err = parse_tc_fdb_actions(priv, &rule->action, flow, extack);
 	if (err)
 		goto err_free;
 
-- 
1.8.3.1

[PATCH net-next 4/5] net/mlx5e: Deletes unnecessary setting of esw_attr->parse_attr

[xiangxia.m.yue]

From: Tonghao Zhang <xiangxia.m.yue@gmail.com>

This patch deletes unnecessary setting of the esw_attr->parse_attr
to parse_attr in parse_tc_fdb_actions() because it is already done
by the mlx5e_flow_esw_attr_init() function.

Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index bbe2374..2d8ffdb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2567,7 +2567,6 @@ static int parse_tc_fdb_actions(struct mlx5e_priv *priv,
 					out_dev->ifindex;
 				parse_attr->tun_info[attr->out_count] = *info;
 				encap = false;
-				attr->parse_attr = parse_attr;
 				attr->dests[attr->out_count].flags |=
 					MLX5_ESW_DEST_ENCAP;
 				attr->out_count++;
-- 
1.8.3.1

[PATCH net-next 5/5] net/mlx5e: Support enable/disable VFs link state on switchdev mode

[xiangxia.m.yue]

From: Tonghao Zhang <xiangxia.m.yue@gmail.com>

This patch allow users to enable/disable VFs link state
on switchdev mode.

Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h      | 1 +
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_rep.c  | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 71c65cc..9f8761f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -1063,5 +1063,6 @@ netdev_features_t mlx5e_features_check(struct sk_buff *skb,
 int mlx5e_set_vf_rate(struct net_device *dev, int vf, int min_tx_rate, int max_tx_rate);
 int mlx5e_get_vf_config(struct net_device *dev, int vf, struct ifla_vf_info *ivi);
 int mlx5e_get_vf_stats(struct net_device *dev, int vf, struct ifla_vf_stats *vf_stats);
+int mlx5e_set_vf_link_state(struct net_device *dev, int vf, int link_state);
 #endif
 #endif /* __MLX5_EN_H__ */
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 878b346..f7475ed 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3956,7 +3956,7 @@ static int mlx5_ifla_link2vport(u8 ifla_link)
 	return MLX5_VPORT_ADMIN_STATE_AUTO;
 }
 
-static int mlx5e_set_vf_link_state(struct net_device *dev, int vf,
+int mlx5e_set_vf_link_state(struct net_device *dev, int vf,
 				   int link_state)
 {
 	struct mlx5e_priv *priv = netdev_priv(dev);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
index 287d48e..d270552 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
@@ -1316,6 +1316,7 @@ static int mlx5e_uplink_rep_set_vf_vlan(struct net_device *dev, int vf, u16 vlan
 	.ndo_set_vf_rate         = mlx5e_set_vf_rate,
 	.ndo_get_vf_config       = mlx5e_get_vf_config,
 	.ndo_get_vf_stats        = mlx5e_get_vf_stats,
+	.ndo_set_vf_link_state   = mlx5e_set_vf_link_state,
 	.ndo_set_vf_vlan         = mlx5e_uplink_rep_set_vf_vlan,
 	.ndo_get_port_parent_id	 = mlx5e_rep_get_port_parent_id,
 };
-- 
1.8.3.1

Re: [PATCH net-next 1/5] net/mlx5e: Return -EOPNOTSUPP when modify header action zero

[Or Gerlitz]

On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
>         else /* namespace is MLX5_FLOW_NAMESPACE_KERNEL - NIC offloading */
>                 max_actions = MLX5_CAP_FLOWTABLE_NIC_RX(priv->mdev, max_modify_header_actions);
>
> +       if (!max_actions) {
> +               NL_SET_ERR_MSG_MOD(extack,
> +                                  "don't support pedit actions, can't offload");
> +               netdev_warn(priv->netdev, "don't support pedit actions, can't offload\n");

it's not going to work if we keep filling the driver with duplicated
error messages, stick to extack only

Also, when you respin with comments provided on this submission,
please send also cover letter
which is  going to be "[PATCH net-next 00/05] ... "  use
--cover-letter for git format-patch and edit it after creation

Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported

[Or Gerlitz]

On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
>
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> If we try to offload decapsulation actions to VFs hw, we get the log [1].

but the switching was on the tunnel  type (if (tunnel_type == [...]) -
what rules caused you to get here?
what was the ingress device and what was the egress (mirred) device?


> It's not friendly, because the kind of net device is null, and we don't
> know what '0' means.
>
> [1] "mlx5_core 0000:05:01.2 vf_0: decapsulation offload is not supported for  net device (0)"

Re: [PATCH net-next 5/5] net/mlx5e: Support enable/disable VFs link state on switchdev mode

[Or Gerlitz]

On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> This patch allow users to enable/disable VFs link state
> on switchdev mode.

NAK

We do it with the reps, if you change the administrative link state of a VF rep
it will effect the operational link state of the VF, see upstream commit

20a1ea674783 net/mlx5e: Support VF vport link state control for SRIOV
switchdev mode

Re: [PATCH net-next 1/5] net/mlx5e: Return -EOPNOTSUPP when modify header action zero

[Tonghao Zhang]

On Fri, Feb 22, 2019 at 12:27 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> >         else /* namespace is MLX5_FLOW_NAMESPACE_KERNEL - NIC offloading */
> >                 max_actions = MLX5_CAP_FLOWTABLE_NIC_RX(priv->mdev, max_modify_header_actions);
> >
> > +       if (!max_actions) {
> > +               NL_SET_ERR_MSG_MOD(extack,
> > +                                  "don't support pedit actions, can't offload");
> > +               netdev_warn(priv->netdev, "don't support pedit actions, can't offload\n");
>
> it's not going to work if we keep filling the driver with duplicated
> error messages, stick to extack only
v2 will be sent
> Also, when you respin with comments provided on this submission,
> please send also cover letter
> which is  going to be "[PATCH net-next 00/05] ... "  use
> --cover-letter for git format-patch and edit it after creation
OK

Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported

[Tonghao Zhang]

On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> >
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > If we try to offload decapsulation actions to VFs hw, we get the log [1].
>
> but the switching was on the tunnel  type (if (tunnel_type == [...]) -
Yes, but we try to offload tc flow to VF device. For example
the  p2p1_0 is VF, but not rep

tc qdisc add dev p2p1_0 ingress
ethtool -K p2p1_0 hw-tc-offload on
tc filter add dev p2p1_0 protocol ip chain 0 parent ffff: prio 1
flower skip_sw dst_mac 00:10:56:fb:64:e8 dst_ip 10.100.3.104 src_ip
10.100.4.0/24 enc_dst_ip 192.168.240.128 enc_key_id 100 enc_dst_port
4789 action tunnel_key unset

> what rules caused you to get here?
> what was the ingress device and what was the egress (mirred) device?
the ingress device  is p2p1_0 (VF), and  the egress (mirred) device is not used

>
> > It's not friendly, because the kind of net device is null, and we don't
> > know what '0' means.
> >
> > [1] "mlx5_core 0000:05:01.2 vf_0: decapsulation offload is not supported for  net device (0)"

Re: [PATCH net-next 5/5] net/mlx5e: Support enable/disable VFs link state on switchdev mode

[Tonghao Zhang]

On Fri, Feb 22, 2019 at 1:03 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > This patch allow users to enable/disable VFs link state
> > on switchdev mode.
>
> NAK
>
> We do it with the reps, if you change the administrative link state of a VF rep
> it will effect the operational link state of the VF, see upstream commit
>
> 20a1ea674783 net/mlx5e: Support VF vport link state control for SRIOV
> switchdev mode
Thanks，it is useful for us.

Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported

[Or Gerlitz]

On Fri, Feb 22, 2019 at 9:49 AM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
>
> On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> >
> > On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > >
> > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > >
> > > If we try to offload decapsulation actions to VFs hw, we get the log [1].
> >
> > but the switching was on the tunnel  type (if (tunnel_type == [...]) -
> Yes, but we try to offload tc flow to VF device. For example
> the  p2p1_0 is VF, but not rep

so this should go to the nic and not esw tc offload code path in en_tc.c
and the nic path (look for parse_tc_nic_actions or a like) doesn't have
a case for the tunnel key action - you should not have got to this code
at all, please look deeper to realize what is going on there, maybe p2p1_0
is a rep? what does ip -d link show gives on it?

Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported

[Tonghao Zhang]

On Fri, Feb 22, 2019 at 5:07 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Fri, Feb 22, 2019 at 9:49 AM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> >
> > On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > >
> > > On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > > >
> > > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > > >
> > > > If we try to offload decapsulation actions to VFs hw, we get the log [1].
> > >
> > > but the switching was on the tunnel  type (if (tunnel_type == [...]) -
> > Yes, but we try to offload tc flow to VF device. For example
> > the  p2p1_0 is VF, but not rep
>
> so this should go to the nic and not esw tc offload code path in en_tc.c
nic and esw will call parse_cls_flower() to parse the flower flows,
and more information is shown as below.
> and the nic path (look for parse_tc_nic_actions or a like) doesn't have
> a case for the tunnel key action - you should not have got to this code
> at all, please look deeper to realize what is going on there, maybe p2p1_0
> is a rep? what does ip -d link show gives on it?

#  ip -d link
14: eth0_p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state
UP mode DEFAULT group default qlen 1000
    link/ether 98:03:9b:06:d9:09 brd ff:ff:ff:ff:ff:ff promiscuity 0
minmtu 68 maxmtu 9978 addrgenmode none numtxqueues 128 numrxqueues 16
gso_max_size 65536 gso_max_segs 65535 portname p1 switchid
98039b06d909
    vf 0 MAC 00:11:22:33:44:00, spoof checking off, link-state auto,
trust off, query_rss off
    vf 1 MAC 00:11:22:33:44:01, spoof checking off, link-state auto,
trust off, query_rss off
15: eth0_pf1vf0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500
qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 8a:26:c0:33:17:2c brd ff:ff:ff:ff:ff:ff promiscuity 1
minmtu 68 maxmtu 9978 addrgenmode none numtxqueues 16 numrxqueues 16
gso_max_size 65536 gso_max_segs 65535 portname pf1vf0 switchid
98039b06d909
16: eth0_pf1vf1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq
state UP mode DEFAULT group default qlen 1000
    link/ether 96:34:55:5b:42:80 brd ff:ff:ff:ff:ff:ff promiscuity 0
minmtu 68 maxmtu 9978 addrgenmode none numtxqueues 16 numrxqueues 16
gso_max_size 65536 gso_max_segs 65535 portname pf1vf1 switchid
98039b06d909
17: p2p1_0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state
UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:00 brd ff:ff:ff:ff:ff:ff promiscuity 0
minmtu 68 maxmtu 9978 addrgenmode none numtxqueues 64 numrxqueues 8
gso_max_size 65536 gso_max_segs 65535
18: p2p1_1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state
UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:01 brd ff:ff:ff:ff:ff:ff promiscuity 0
minmtu 68 maxmtu 9978 addrgenmode none numtxqueues 64 numrxqueues 8
gso_max_size 65536 gso_max_segs 65535

#  ethtool -i p2p1_0
driver: mlx5_core
version: 5.0-0
firmware-version: 14.24.1000 (MT_2420110034)
bus-info: 0000:05:01.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

# ethtool -i eth0_pf1vf0
driver: mlx5e_rep
version: 5.0.0-rc7+
firmware-version:
bus-info:
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no


the call trace:
[  586.669600]  dump_stack+0x5a/0x73
[  586.669651]  mlx5e_tc_tun_parse+0x2c6/0x3a0 [mlx5_core]
[  586.669682]  __parse_cls_flower.constprop.48+0x1b2/0xca0 [mlx5_core]
[  586.669746]  parse_cls_flower+0x5d/0x110 [mlx5_core]
[  586.669771]  mlx5e_configure_flower+0x40a/0x760 [mlx5_core]
[  586.669779]  tc_setup_cb_call+0x55/0x80
[  586.669787]  fl_change+0x12a1/0x16b8 [cls_flower]
[  586.669797]  tc_new_tfilter+0x570/0x890
[  586.669808]  rtnetlink_rcv_msg+0xed/0x320
[  586.669817]  netlink_rcv_skb+0xcb/0x100
[  586.669822]  netlink_unicast+0x17f/0x230
[  586.669827]  netlink_sendmsg+0x2d2/0x3d0

Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported

[Or Gerlitz]

On Sat, Feb 23, 2019 at 9:58 AM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> On Fri, Feb 22, 2019 at 5:07 PM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > On Fri, Feb 22, 2019 at 9:49 AM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
> > > On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> > > > On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > > > >
> > > > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > > > >
> > > > > If we try to offload decapsulation actions to VFs hw, we get the log [1].
> > > >
> > > > but the switching was on the tunnel  type (if (tunnel_type == [...]) -
> > > Yes, but we try to offload tc flow to VF device. For example
> > > the  p2p1_0 is VF, but not rep


>> so this should go to the nic and not esw tc offload code path in en_tc.c

> nic and esw will call parse_cls_flower() to parse the flower flows,
> and more information is shown as below.

ok, got you. We err on the match parsing stage, this is relatively
new.. up to 5.0
we were erring only on the  action parsing stage. The patch seems fine, it would
be good to modify  mlx5e_netdev_kind() to return "unkown" and not the
empty string
("") when the netdev doesn't have a kind assigned (can do this in this patch).