Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2788266imm; Mon, 16 Jul 2018 14:18:26 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc20VjbzORR+R1s7PoL+I8o0GbM24EzUPesCYRYHighO/V/95mqjvgCx23RWzR64vFbSsXn X-Received: by 2002:aa7:88d3:: with SMTP id p19-v6mr19613462pfo.160.1531775906578; Mon, 16 Jul 2018 14:18:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531775906; cv=none; d=google.com; s=arc-20160816; b=Hv0/IkYwmO59XwrmfA268BREJC7BBYYVgwXTEV41EgSwXy810vT+psvfbTcUJ+ptLx Ay2CMLrBHNUu0I2r1TwYXfU9XgldoSy5NOCryKSITpCDJyvnuNho1kZrSuXj+p6tNZvw 8AdqJ42cPeAjagj6zKgGWtQj8jPGzs3lLzqn76snnNs/94qnP7cDrJUgaPUBO5UHxYiR 80dgHJXFdSwaEzHIa1PcYSTa1DB2G1siT2qTD1jfq89YA7VSw7uuLeVUFBxBBI5dzlX0 82G5VSoa/7MDXijnBSVa3PgXVaaGZDRe0ZdGLuVQgkJtkhisGWFnzOBRHJmO/kI3yuDV LnVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=rBnKpGEjMP3TVOejYA8BIy0ie1XXMiwJTOnZchw5wjI=; b=RqgYFfxkgsqx/dYsuyf2c6IAK6ompwA37d5Mx1ZWvh66r38SfXWLDksKqiMTA/jDHB q7RWq2WtVPFTsG3JJHHsDiQjIpP61YgQa6gpE/nraaE8XLW/Bugy20EWGLSJP+yRO/fa RSmh/yD6MEjXR02cCmy5x6+sVo31KWDF9CZhnG5BIGkfNBlHxk4rfUwwu+gV9aPcOscX APFTcoQtebAW0GepwVU5wCWsixUTDbVS/b7FEd7RLCWpFQWtmsedl24fxNBVqRGEfP9+ GThEVXlC8OCVsF8Um+XlXcEgFdFDBa1USy5uzGBbMuOY7V6RvgtnsY/Sumk5iYSW59iz hlvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=m77uBRp2; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 69-v6si31279494pla.288.2018.07.16.14.18.11; Mon, 16 Jul 2018 14:18:26 -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=@kernel.org header.s=default header.b=m77uBRp2; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730079AbeGPVqW (ORCPT + 99 others); Mon, 16 Jul 2018 17:46:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:43832 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728413AbeGPVqW (ORCPT ); Mon, 16 Jul 2018 17:46:22 -0400 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 724A92086E; Mon, 16 Jul 2018 21:17:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1531775828; bh=6DBwRiLN2FUonYoUzeBIDnNc4XDFdg+X5pLq2DQM5xs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m77uBRp2pDv5NFrm9LZ806z2162srD0QGV9Y/+MJQ2UYOik+JKwj8Q60iFYV3zIrH wQTT1As+zHn/ot29iL4VZSUW9S1kvfkuUP4zPikCMAkniglJiiQ6TmoKylEou384gL TFhGkhGuIZbZtp41f0ipIs+YajnlmMG220kvru6E= Date: Mon, 16 Jul 2018 16:17:06 -0500 From: Bjorn Helgaas To: Alexandru Gagniuc Cc: bhelgaas@google.com, alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, keith.busch@intel.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Jeff Kirsher , Ariel Elior , Michael Chan , Ganesh Goudar , Tariq Toukan , Jakub Kicinski , Tal Gilboa , Dave Airlie , Alex Deucher Subject: Re: [PATCH v3] PCI: Check for PCIe downtraining conditions Message-ID: <20180716211706.GB12391@bhelgaas-glaptop.roam.corp.google.com> References: <20180604155523.14906-1-mr.nuke.me@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180604155523.14906-1-mr.nuke.me@gmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [+cc maintainers of drivers that already use pcie_print_link_status() and GPU folks] On Mon, Jun 04, 2018 at 10:55:21AM -0500, Alexandru Gagniuc wrote: > PCIe downtraining happens when both the device and PCIe port are > capable of a larger bus width or higher speed than negotiated. > Downtraining might be indicative of other problems in the system, and > identifying this from userspace is neither intuitive, nor straigh > forward. s/straigh/straight/ In this context, I think "straightforward" should be closed up (without the space). > The easiest way to detect this is with pcie_print_link_status(), > since the bottleneck is usually the link that is downtrained. It's not > a perfect solution, but it works extremely well in most cases. This is an interesting idea. I have two concerns: Some drivers already do this on their own, and we probably don't want duplicate output for those devices. In most cases (ixgbe and mlx* are exceptions), the drivers do this unconditionally so we *could* remove it from the driver if we add it to the core. The dmesg order would change, and the message wouldn't be associated with the driver as it now is. Also, I think some of the GPU devices might come up at a lower speed, then download firmware, then reset the device so it comes up at a higher speed. I think this patch will make us complain about about the low initial speed, which might confuse users. So I'm not sure whether it's better to do this in the core for all devices, or if we should just add it to the high-performance drivers that really care. > Signed-off-by: Alexandru Gagniuc > --- > > Changes since v2: > - Check dev->is_virtfn flag > > Changes since v1: > - Use pcie_print_link_status() instead of reimplementing logic > > drivers/pci/probe.c | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index ac91b6fd0bcd..a88ec8c25dd5 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -2146,6 +2146,25 @@ static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn) > return dev; > } > > +static void pcie_check_upstream_link(struct pci_dev *dev) > +{ > + > + if (!pci_is_pcie(dev)) > + return; > + > + /* Look from the device up to avoid downstream ports with no devices. */ > + if ((pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT) && > + (pci_pcie_type(dev) != PCI_EXP_TYPE_LEG_END) && > + (pci_pcie_type(dev) != PCI_EXP_TYPE_UPSTREAM)) > + return; Do we care about Upstream Ports here? I suspect that ultimately we only care about the bandwidth to Endpoints, and if an Endpoint is constrained by a slow link farther up the tree, pcie_print_link_status() is supposed to identify that slow link. I would find this test easier to read as if (!(type == PCI_EXP_TYPE_ENDPOINT || type == PCI_EXP_TYPE_LEG_END)) return; But maybe I'm the only one that finds the conjunction of inequalities hard to read. No big deal either way. > + /* Multi-function PCIe share the same link/status. */ > + if ((PCI_FUNC(dev->devfn) != 0) || dev->is_virtfn) > + return; > + > + pcie_print_link_status(dev); > +} > + > static void pci_init_capabilities(struct pci_dev *dev) > { > /* Enhanced Allocation */ > @@ -2181,6 +2200,9 @@ static void pci_init_capabilities(struct pci_dev *dev) > /* Advanced Error Reporting */ > pci_aer_init(dev); > > + /* Check link and detect downtrain errors */ > + pcie_check_upstream_link(dev); > + > if (pci_probe_reset_function(dev) == 0) > dev->reset_fn = 1; > } > -- > 2.14.4 >