i40e: don't hold RTNL lock for the entire reset
authorJacob Keller <jacob.e.keller@intel.com>
Wed, 7 Jun 2017 09:43:13 +0000 (05:43 -0400)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Wed, 21 Jun 2017 01:17:12 +0000 (18:17 -0700)
commitdfc4ff644674a133878aded9a86ab36c358f3138
tree1a61b14e6caf52337aa1dc58eb311cc34db3edfc
parent7642984b08760b8d0ff7f4cfbe524bb53eb4cec2
i40e: don't hold RTNL lock for the entire reset

We recently refactored i40e_do_reset() and its friends to be able to
hold the RTNL lock only for the portions that actually need to be
protected. However, a separate refactoring added several new callers of
these functions during the PCIe error recovery and suspend/resume
cycles.

When merging the changes together, it was not noticed that we could
reduce the RTNL scope by letting the reset function handle the lock
itself, as previously it was not possible.

Fix this by replacing these call sites to indicate that the reset
function should handle its own lock. This enables multiple PFs to reset
or resume simultaneously without serializing the resets via the RTNL
lock. The end result is that on systems with lots of PFs and VFs the
resets don't stall waiting for each other to finish.

It is probable that we can also do the same for i40e_do_reset_safe, but
this author did not research that change carefully enough to be
confident.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/i40e/i40e_main.c