Message-ID: <20190809220359.11516-1-saeedm@mellanox.com>
Date:   Fri, 9 Aug 2019 22:04:17 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "David S. Miller" <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Saeed Mahameed <saeedm@...lanox.com>
Subject: [pull request][net-next 00/15] Mellanox, mlx5 tc flow handling for
 concurrent execution (Part 2)

Hi Dave,

This series, mostly from Vlad, is the 2nd part of 3 part series to
improve mlx5 tc flow handling by removing dependency on rtnl_lock and
providing a more fine-grained locking and rcu safe data structures to
allow tc flow handling for concurrent execution.

In this part Vlad handles hairpin, header rewrite and encapsulation
offloads.

For more information please see tag log below.

Please pull and let me know if there is any problem.

Thanks,
Saeed.


---
The following changes since commit ca497fb6aa9fbd3b0a87fd0a71e9e1df2600ac30:

  taprio: remove unused variable 'entry_list_policy' (2019-08-09 13:41:24 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2019-08-09

for you to fetch changes up to b51c225e6c4e987e131b8b1332f66969382bf328:

  net/mlx5e: Use refcount_t for refcount (2019-08-09 14:54:11 -0700)

----------------------------------------------------------------
mlx5-updates-2019-08-09

This series includes update to mlx5 ethernet and core driver:

In first #11 patches, Vlad submits part 2 of 3 part series to allow
TC flow handling for concurrent execution.

1) TC flow handling for concurrent execution (part 2)

Vald Says:
==========

Refactor data structures that are shared between flows in tc.
Currently, all cls API hardware offloads driver callbacks require caller
to hold rtnl lock when calling them. Cls API has already been updated to
update software filters in parallel (on classifiers that support
unlocked execution), however hardware offloads code still obtains rtnl
lock before calling driver tc callbacks. This set implements support for
unlocked execution of tc hairpin, mod_hdr and encap subsystem. The
changed implemented in these subsystems are very similar in general.

The main difference is that hairpin is accessed through mlx5e_tc_table
(legacy mode), mod_hdr is accessed through both mlx5e_tc_table and
mlx5_esw_offload (legacy and switchdev modes) and encap is only accessed
through mlx5_esw_offload (switchdev mode).

1.1) Hairpin handling and structure mlx5e_hairpin_entry refactored in
following way:

- Hairpin structure is extended with atomic reference counter. This
  approach allows to lookup of hairpin entry and obtain reference to it
  with hairpin_tbl_lock protection and then continue using the entry
  unlocked (including provisioning to hardware).

- To support unlocked provisioning of hairpin entry to hardware, the entry
  is extended with 'res_ready' completion and is inserted to hairpin_tbl
  before calling the firmware. With this approach any concurrent users that
  attempt to use the same hairpin entry wait for completion first to
  prevent access to entries that are not fully initialized.

- Hairpin entry is extended with new flows_lock spinlock to protect the
  list when multiple concurrent tc instances update flows attached to
  the same hairpin entry.

1.2) Modify header handling code and structure mlx5e_mod_hdr_entry
are refactored in the following way:

- Mod_hdr structure is extended with atomic reference counter. This
  approach allows to lookup of mod_hdr entry and obtain reference to it
  with mod_hdr_tbl_lock protection and then continue using the entry
  unlocked (including provisioning to hardware).

- To support unlocked provisioning of mod_hdr entry to hardware, the entry
  is extended with 'res_ready' completion and is inserted to mod_hdr_tbl
  before calling the firmware. With this approach any concurrent users that
  attempt to use the same mod_hdr entry wait for completion first to
  prevent access to entries that are not fully initialized.

- Mod_Hdr entry is extended with new flows_lock spinlock to protect the
  list when multiple concurrent tc instances update flows attached to
  the same mod_hdr entry.

1.3) Encapsulation handling code and Structure mlx5e_encap_entry
are refactored in the following way:

- encap structure is extended with atomic reference counter. This
  approach allows to lookup of encap entry and obtain reference to it
  with encap_tbl_lock protection and then continue using the entry
  unlocked (including provisioning to hardware).

- To support unlocked provisioning of encap entry to hardware, the entry is
  extended with 'res_ready' completion and is inserted to encap_tbl before
  calling the firmware. With this approach any concurrent users that
  attempt to use the same encap entry wait for completion first to prevent
  access to entries that are not fully initialized.

- As a difference from approach used to refactor hairpin and mod_hdr,
  encap entry is not extended with any per-entry fine-grained lock.
  Instead, encap_table_lock is used to synchronize all operations on
  encap table and instances of mlx5e_encap_entry. This is necessary
  because single flow can be attached to multiple encap entries
  simultaneously. During new flow creation or neigh update event all of
  encaps that flow is attached to must be accessed together as in atomic
  manner, which makes usage of per-entry lock infeasible.

- Encap entry is extended with new flows_lock spinlock to protect the
  list when multiple concurrent tc instances update flows attached to
  the same encap entry.

==========

3) Parav improves the way port representors report their parent ID and
port index.

4) Use refcount_t for refcount in vxlan data base from  Chuhong Yuan

----------------------------------------------------------------
Chuhong Yuan (1):
      net/mlx5e: Use refcount_t for refcount

Parav Pandit (3):
      net/mlx5: E-switch, Removed unused hwid
      net/mlx5e: Simplify querying port representor parent id
      net/mlx5e: Use vhca_id in generating representor port_index

Vlad Buslov (11):
      net/mlx5e: Extend hairpin entry with reference counter
      net/mlx5e: Protect hairpin entry flows list with spinlock
      net/mlx5e: Protect hairpin hash table with mutex
      net/mlx5e: Allow concurrent creation of hairpin entries
      net/mlx5e: Extend mod header entry with reference counter
      net/mlx5e: Protect mod header entry flows list with spinlock
      net/mlx5e: Protect mod_hdr hash table with mutex
      net/mlx5e: Allow concurrent creation of mod_hdr entries
      net/mlx5e: Extend encap entry with reference counter
      net/mlx5e: Protect encap hash table with mutex
      net/mlx5e: Allow concurrent creation of encap entries

 drivers/net/ethernet/mellanox/mlx5/core/en/fs.h    |   3 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_rep.c   |  41 ++-
 drivers/net/ethernet/mellanox/mlx5/core/en_rep.h   |   3 +
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c    | 401 +++++++++++++++------
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.h    |   2 +
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c  |   6 +-
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.h  |   3 +-
 .../ethernet/mellanox/mlx5/core/eswitch_offloads.c |   6 +-
 .../net/ethernet/mellanox/mlx5/core/lib/vxlan.c    |   9 +-
 include/linux/mlx5/eswitch.h                       |   1 -
 include/linux/mlx5/fs.h                            |   5 +
 11 files changed, 340 insertions(+), 140 deletions(-)

Powered by blists - more mailing lists