net/mlx5e: Use a slow path rule instead if vxlan neighbour isn't available
authorPaul Blakey <paulb@mellanox.com>
Wed, 1 Aug 2018 08:09:10 +0000 (11:09 +0300)
committerSaeed Mahameed <saeedm@mellanox.com>
Wed, 17 Oct 2018 21:20:49 +0000 (14:20 -0700)
commit5dbe906ff1d5040013d30df1e8c769d28af7e0f9
tree8a8b5dfb80f96073d6d3be6a5f3d80dae4856549
parentc92a0b9457a4e44e1e7f53785490a5482eedfe2d
net/mlx5e: Use a slow path rule instead if vxlan neighbour isn't available

When adding a vxlan tc rule, and a neighbour isn't available, we
don't insert any rule to hardware. Once we enable offloading flows
with multiple priorities, a packet that should have matched this rule
will continue in hardware pipeline and might match a wrong one.

This is unlike in tc software path where it will be matched and
forwarded to the vxlan device (which will cause a ARP lookup
eventually) and stop processing further tc filters.

To address that, when when a neighbour isn't available (EAGAIN from
attach_encap), or gets deleted, change the original action to be a
forward to slow path instead. Neighbour update will restore the original
action once the neighbour becomes available. This will be done atomically
so at any given time we will have a the correct match.

Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c