From: Saeed Mahameed <saeedm@mellanox.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Saeed Mahameed <saeedm@mellanox.com>
Subject: [pull request][net-next 00/13] Mellanox, mlx5 tc flow handling for concurrent execution (Part 1)
Date: Mon, 29 Jul 2019 23:50:14 +0000 [thread overview]
Message-ID: <20190729234934.23595-1-saeedm@mellanox.com> (raw)
Hi Dave,
This series, mostly from Vlad, is the first part of ongoing work to
improve mlx5 tc flow handling by removing dependency on rtnl_lock and
providing a more fine-grained locking and rcu safe data structures.
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 85fd8011475e86265beff7b7617c493c247f5356:
Merge branch 'bnxt_en-TPA-57500' (2019-07-29 14:19:09 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2019-07-29
for you to fetch changes up to b6fac0b46a1a76024698d240f0f9aac552f897b7:
net/mlx5e: Protect tc flow table with mutex (2019-07-29 16:40:26 -0700)
----------------------------------------------------------------
mlx5-updates-2019-07-29
This series includes updates to mlx5 driver,
1) Simplifications, cleanup and warning prints improvements
2) From Vlad Buslov:
Refactor mlx5 tc flow handling for unlocked execution (Part 1)
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 partial
support for unlocked execution that is leveraged by follow up
refactorings in specific mlx5 tc subsystems and patch to cls API that
implements API that allows drivers to register their callbacks as
rtnl-unlocked.
In mlx5 tc code mlx5e_tc_flow is the main structure that is used to
represent tc filter. Currently, code the structure itself and its
handlers in both tc and eswitch layers do not implement any kind of
synchronizations and assume external global synchronization provided by
rtnl lock instead. Implement following changes to remove dependency on
rtnl lock in flow handling code that are intended to be used a
groundwork for following changes to provide fully rtnl-independent mlx5
tc:
- Extend struct mlx5e_tc_flow with atomic reference counter and rcu to
allow concurrent access from multiple tc and neigh update workqueue
instances without introducing any additional locks specific to the
structure. Its 'flags' field type is changed to atomic bitmask ops which
is necessary for tc to interact with other concurrent tc instances or
concurrent neigh update that need to skip flows that are not fully
initialized (new INIT_DONE flow flag) and can change the flags
according to neighbor state (flipping OFFLOADED flag).
- Protect unready flows list by new uplink_priv->unready_flows_lock
mutex.
- Convert calls to netdev APIs that require rtnl lock in flow handling
code to their rcu counterparts.
- Modify eswitch code that is called from tc layer and assume implicit
external synchronization to be concurrency safe: change
esw->offloads.num_flows type to atomic integer and re-arrange
esw->state_lock usage to protect additional data.
Some of approaches to synchronizations presented in this patch set are
quite complicated (lockless concurrent usage of data structures with rcu
and reference counting, using fine-grained locking when necessary, retry
mechanisms to handle concurrent insertion of another instance of data
structure with same key, etc.). This is necessary to allow calling the
firmware in parallel in most cases, which is the main motivation of this
change since firmware calls are mach heavier operation than atomic
operations, multitude of locks and potential multiple retries during
concurrent accesses to same elements.
----------------------------------------------------------------
Eli Britstein (1):
net/mlx5e: Simplify get_route_and_out_devs helper function
Huy Nguyen (1):
net/mlx5e: Print a warning when LRO feature is dropped or not allowed
Saeed Mahameed (2):
net/mlx5e: Avoid warning print when not required
net/mlx5e: Improve ethtool rxnfc callback structure
Vlad Buslov (8):
net/mlx5e: Extend tc flow struct with reference counter
net/mlx5e: Change flow flags type to unsigned long
net/mlx5e: Protect tc flows hashtable with rcu
net/mlx5e: Protect unready flows with dedicated lock
net/mlx5e: Eswitch, change offloads num_flows type to atomic64
net/mlx5e: Eswitch, use state_lock to synchronize vlan change
net/mlx5e: Rely on rcu instead of rtnl lock when getting upper dev
net/mlx5e: Protect tc flow table with mutex
wenxu (1):
net/mlx5e: Fix unnecessary flow_block_cb_is_busy call
drivers/net/ethernet/mellanox/mlx5/core/en/fs.h | 13 +-
.../net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 33 +-
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 28 +-
.../ethernet/mellanox/mlx5/core/en_fs_ethtool.c | 11 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 16 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 12 +-
drivers/net/ethernet/mellanox/mlx5/core/en_rep.h | 2 +
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 492 +++++++++++++--------
drivers/net/ethernet/mellanox/mlx5/core/en_tc.h | 26 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 16 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 3 +-
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 27 +-
12 files changed, 424 insertions(+), 255 deletions(-)
next reply other threads:[~2019-07-29 23:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 23:50 Saeed Mahameed [this message]
2019-07-29 23:50 ` [net-next 01/13] net/mlx5e: Print a warning when LRO feature is dropped or not allowed Saeed Mahameed
2019-07-30 15:52 ` Willem de Bruijn
2019-07-30 20:07 ` Saeed Mahameed
2019-07-30 21:34 ` Willem de Bruijn
2019-07-29 23:50 ` [net-next 02/13] net/mlx5e: Avoid warning print when not required Saeed Mahameed
2019-07-29 23:50 ` [net-next 03/13] net/mlx5e: Improve ethtool rxnfc callback structure Saeed Mahameed
2019-07-29 23:50 ` [net-next 04/13] net/mlx5e: Fix unnecessary flow_block_cb_is_busy call Saeed Mahameed
2019-07-29 23:50 ` [net-next 05/13] net/mlx5e: Simplify get_route_and_out_devs helper function Saeed Mahameed
2019-07-29 23:50 ` [net-next 06/13] net/mlx5e: Extend tc flow struct with reference counter Saeed Mahameed
2019-07-29 23:50 ` [net-next 07/13] net/mlx5e: Change flow flags type to unsigned long Saeed Mahameed
2019-07-29 23:50 ` [net-next 08/13] net/mlx5e: Protect tc flows hashtable with rcu Saeed Mahameed
2019-07-30 16:15 ` Willem de Bruijn
2019-07-30 16:37 ` Willem de Bruijn
2019-07-30 20:09 ` Saeed Mahameed
2019-07-29 23:50 ` [net-next 09/13] net/mlx5e: Protect unready flows with dedicated lock Saeed Mahameed
2019-07-29 23:50 ` [net-next 10/13] net/mlx5e: Eswitch, change offloads num_flows type to atomic64 Saeed Mahameed
2019-07-29 23:50 ` [net-next 11/13] net/mlx5e: Eswitch, use state_lock to synchronize vlan change Saeed Mahameed
2019-07-29 23:50 ` [net-next 12/13] net/mlx5e: Rely on rcu instead of rtnl lock when getting upper dev Saeed Mahameed
2019-07-29 23:50 ` [net-next 13/13] net/mlx5e: Protect tc flow table with mutex Saeed Mahameed
2019-07-31 22:48 ` [pull request][net-next 00/13] Mellanox, mlx5 tc flow handling for concurrent execution (Part 1) David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190729234934.23595-1-saeedm@mellanox.com \
--to=saeedm@mellanox.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox