net/mlx5e: Refactor neigh update for concurrent execution
In order to remove dependency on rtnl lock and allow neigh update workqueue task to execute concurrently with tc, refactor mlx5e_rep_neigh_update() for concurrent execution: - Lock encap table when accessing encap entry to prevent concurrent changes. To do this properly, the initial encap state check is moved from mlx5e_rep_neigh_update() into mlx5e_rep_update_flows() to be performed under encap_tbl_lock protection. - Wait for encap to be fully initialized before accessing it by means of 'res_ready' completion. - Add mlx5e_take_all_encap_flows() helper which is used to construct a temporary list of flows and efi indexes that is used to access current encap data in flow which can be attached to multiple encaps simultaneously. Release the flows from temporary list after encap_tbl_lock critical section. This is necessary because mlx5e_flow_put() can't be called while holding encap_tbl_lock. - Modify mlx5e_tc_encap_flows_add() and mlx5e_tc_encap_flows_del() to work with user-provided list of flows built by mlx5e_take_all_encap_flows(), instead of traversing encap flow list directly. This is first step in complex neigh update refactoring, which is finished by following commit in this series. Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Showing
Please register or sign in to comment