Re: [PATCH net-next 0/7] nfp: flower vxlan tunnel offload
From: Or Gerlitz <hidden>
Date: 2017-09-26 12:41:39
On Tue, Sep 26, 2017 at 1:15 PM, Jiri Benc [off-list ref] wrote:
On Mon, 25 Sep 2017 19:04:53 +0200, Simon Horman wrote:quoted
The MAC addresses are extracted from the netdevs already loaded in the kernel and are monitored for any changes. The IP addresses are slightly different in that they are extracted from the rules themselves. We make the assumption that, if a packet is decapsulated at the end point and a match is attempted on the IP address,You lost me here, I'm afraid. What do you mean by "match"?quoted
that this IP address should be recognised in the kernel. That being the case, the same traffic pattern should be witnessed if the skip_hw flag is applied.Just to be really sure that this works correctly, can you confirm that this will match the packet: ip link add vxlan0 type vxlan dstport 4789 dev eth0 external ip link set dev vxlan0 up tc qdisc add dev vxlan0 ingress ethtool -K eth0 hw-tc-offload on tc filter add dev vxlan0 protocol ip parent ffff: flower enc_key_id 102 \ enc_dst_port 4789 src_ip 3.4.5.6 skip_sw action [...] while this one will NOT match:
what do you exactly mean by "will not match"
ip link add vxlan0 type vxlan dstport 4789 dev eth0 external ip link set dev vxlan0 up tc qdisc add dev eth0 ingress ethtool -K eth0 hw-tc-offload on tc filter add dev eth0 protocol ip parent ffff: flower enc_key_id 102 \ enc_dst_port 4789 src_ip 3.4.5.6 skip_sw action [...]
Please note that the way the rule is being set to the HW driver is by delegation done in flower, see these commits (specifically "Add offload support using egress Hardware device") a6e1693 net/sched: cls_flower: Set the filter Hardware device for all use-cases 7091d8c net/sched: cls_flower: Add offload support using egress Hardware device 255cb30 net/sched: act_mirred: Add new tc_action_ops get_dev() Since the egress port is not HW port netdev but rather SW virtual tunnel netdev we have some logic in the kernel to delegate the rule programming to HW via the HW netdev OKay? if not, please elaborate
We found that with mlx5, the second one actually matches, too. Which is a very serious bug. (Adding Paolo who found this. And adding a few more Mellanox guys to be aware of the bug.)
What is the bug in your view? Or.