On Mon, 25 Sep 2017 19:04:53 +0200, Simon Horman wrote: > 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"? > 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: 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 [...] 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.) Jiri
