| Message ID | 1550715283-23579-2-git-send-email-xiangxia.m.yue@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net-next,1/5] net/mlx5e: Return -EOPNOTSUPP when modify header action zero | expand |
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)"
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)"
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?
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
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).
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;