Received: by 10.192.165.148 with SMTP id m20csp1842365imm; Thu, 3 May 2018 06:21:15 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo9QPwfcBGJksGJxdkyjj8Es9ehV1TLPsBFhGvcudbDDxFPmK6wl0cVbUudeMxkY+n0pU0A X-Received: by 10.98.21.73 with SMTP id 70mr23186956pfv.91.1525353675368; Thu, 03 May 2018 06:21:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525353675; cv=none; d=google.com; s=arc-20160816; b=qw9T6TBb7Op/1T7Qb3iEFqWU5cx07kj35JYz7GNt9UyjjBNZWRdaPORxk+VHihhhWq QF4Z5TXphShXv4ZrgZ4KlCVvGrQ2lG7z58sw7lclV9OuJB3+JZttDf7Ve8tQmtSeMp/d 3J7yGqnHpfXlrXoKP/FNMjmeS4mtdPrrXvBAtld69NjzIFU61zISdiI+tu3YMMNY0+Qc TYnDLa6bQJmtDXFg5M21rSLcbN9cOkqleWFzqUOlyQrUDaUG+x1eaFGM4sAAGwvZa+ZF Xv2/147nNG59GUF0uy4XoQ0/wY6GZzjYRiVgMQ18KfGq96A/e/n497tpzdupaAqqNb9J lvHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=nsdGvjvAAsPmH8HW3yn2fqaR+LQ3M1tcdC+qIblcBLU=; b=zaYXjve27zbxkPjKlmhUi8F/Ty9yi347UjcuM63QkeueyEQuSrH3pNspmeoYSZORni MgOH1jymoOasO6gqb8qlnpYaIwLu6LNX6IGXbv9GBRK/lSUHrIuCiYSAr/BDKBMdJtvI eQO3jMZ420aeYHOk/q/ZQvwuz5enoVha10fSqhyJwgkJwrAmOTILRVGDDr+tvl2Nbh9V WiD7tTknJ0seSyoKNAPLfHNHiuaF2l194sbvrD7buZoKehGsGK7aazzE/JP4cZeGnoBl hnbE2Amos/uqTiWpyZouRntQxs51DVUhCROD5H5Q1hPP0kAQFODGXqAOsa0MbxAojkpS VUcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rof04DiM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w68si10028003pfb.325.2018.05.03.06.21.00; Thu, 03 May 2018 06:21:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rof04DiM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751339AbeECNUL (ORCPT + 99 others); Thu, 3 May 2018 09:20:11 -0400 Received: from mail-ot0-f194.google.com ([74.125.82.194]:40693 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbeECNUI (ORCPT ); Thu, 3 May 2018 09:20:08 -0400 Received: by mail-ot0-f194.google.com with SMTP id n1-v6so20575820otf.7; Thu, 03 May 2018 06:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nsdGvjvAAsPmH8HW3yn2fqaR+LQ3M1tcdC+qIblcBLU=; b=rof04DiMfmDkuFZO2ty2wOsqsHiYkVB6Bk9owJ0QaMVn9xe1L8y4Q6LAxfsAfXcSUH wpQyirkDFxDN0+9vl3QNewOCQpMj+m4mkZsq4HNKbpjwSAviCW0/XBUS1DFzDxxal4pG k4hTlBkuuIVPFDXkDQTdJTczc7Nkyu6h8gZwsu/ym+MkFnIXcqa7LLQ7OBsFm/MD0/xI cYLxi+OeQpWuj8cXnmB4Z04FTX98QgsPEEVq6ho/6qhjaaAhCJjST9eaFuWVuUSpRCr7 DRIH42JE1fX3mPc9dJSJuXG9baMaHDK/A/MJPUMqaHHTYw8jw6vV7WWvUoijEIfoyd4p O91Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nsdGvjvAAsPmH8HW3yn2fqaR+LQ3M1tcdC+qIblcBLU=; b=MB+4zB8qrF8fvTwwvYvfRwtxr5C5h9f+2GMDhrv37YW3vopsyvflm6nIyVIKMoGqxJ avB19gin7bdtp7+8/uHhdf7OtIh44CE5dXG1Lgm+BijPe2wdIo7dWBV7nB52YqgwWCnG 1Irci3gM8MVpgIpDCrOE2kncE0idq2NzPHCeRMgsXEa7IG+ZIUWtvCffQpbPkzcEHbXZ YgpghLa58XrnwqVGMTdD4Gv7Yv0+ZeevU6xYssgpSjsPWyX0EMKK7re1filHPb5dVTVS 6390MvxrdXMpT+ghKBq0BIgEhLdi6K8SV+g/sPzngDc1RLNNz/wKr0FqO9SUkcAXEhBy 8a/Q== X-Gm-Message-State: ALQs6tB76EtzXgEmrZVCCIMdgB23E3ufTMXc+f3reYxgEtnUQsNPerEg zYfGh8Q7Knx8bWxC22czk1tpUAroHFSt0vT7vwQ= X-Received: by 2002:a9d:72b:: with SMTP id 40-v6mr17305317ote.145.1525353607687; Thu, 03 May 2018 06:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.10.209 with HTTP; Thu, 3 May 2018 06:20:07 -0700 (PDT) In-Reply-To: <20180503035931.22439-2-pasha.tatashin@oracle.com> References: <20180503035931.22439-1-pasha.tatashin@oracle.com> <20180503035931.22439-2-pasha.tatashin@oracle.com> From: Alexander Duyck Date: Thu, 3 May 2018 06:20:07 -0700 Message-ID: Subject: Re: [PATCH 1/2] ixgbe: release lock for the duration of ixgbe_suspend_close() To: Pavel Tatashin Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, LKML , Jeff Kirsher , intel-wired-lan , Netdev , Greg KH Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 2, 2018 at 8:59 PM, Pavel Tatashin wrote: > Currently, during device_shutdown() ixgbe holds rtnl_lock for the duration > of lengthy ixgbe_close_suspend(). On machines with multiple ixgbe cards > this lock prevents scaling if device_shutdown() function is multi-threaded. > > It is not necessary to hold this lock during ixgbe_close_suspend() > as it is not held when ixgbe_close() is called also during shutdown but for > kexec case. > > Signed-off-by: Pavel Tatashin > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > index afadba99f7b8..e7875b58854b 100644 > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c > @@ -6748,8 +6748,15 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake) > rtnl_lock(); > netif_device_detach(netdev); > > - if (netif_running(netdev)) > + if (netif_running(netdev)) { > + /* Suspend takes a long time, device_shutdown may be > + * parallelized this function, so drop lock for the > + * duration of this call. > + */ > + rtnl_unlock(); > ixgbe_close_suspend(adapter); > + rtnl_lock(); > + } > > ixgbe_clear_interrupt_scheme(adapter); > rtnl_unlock(); I'm not a fan of dropping the mutex while we go through ixgbe_close_suspend. I'm concerned it will result in us having a number of races on shutdown. If anything, I think we would need to find a replacement for the mutex that can operate at the per-netdev level if you are wanting to parallelize this. - Alex