diff options
author | Vlad Buslov <vladbu@mellanox.com> | 2019-08-04 12:25:57 +0300 |
---|---|---|
committer | Saeed Mahameed <saeedm@mellanox.com> | 2019-08-21 15:55:17 -0700 |
commit | 2a1f1768fa17805ca2e937e2e034a7c3433d3bdc (patch) | |
tree | 5d60669efcc68d884101be755b2b5b4d1388aaf3 /Documentation | |
parent | 6a06c2f7843d85b43ccea6e89de8e432834c089b (diff) |
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>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions