From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755688AbcFQWGJ (ORCPT ); Fri, 17 Jun 2016 18:06:09 -0400 Received: from mga14.intel.com ([192.55.52.115]:12087 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751162AbcFQWGH (ORCPT ); Fri, 17 Jun 2016 18:06:07 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,485,1459839600"; d="scan'208";a="721157326" From: Ashutosh Dixit To: Bjorn Helgaas Cc: "Marciniszyn\, Mike" , "Dalessandro\, Dennis" , Doug Ledford , "Hefty\, Sean" , Hal Rosenstock , "linux-rdma\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "linux-pci\@vger.kernel.org" Subject: Re: hfi1 use of PCI internals References: <20160616162052.GA2144@localhost> <20160616200817.GA17778@localhost> Date: Fri, 17 Jun 2016 18:05:43 -0400 In-Reply-To: <20160616200817.GA17778@localhost> (Bjorn Helgaas's message of "Thu, 16 Jun 2016 14:08:17 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 16 2016 at 04:08:17 PM, Bjorn Helgaas wrote: > > That's a good start, but leads to more questions. For example, it > doesn't answer the obvious question of why the driver needs to > enable/disable ASPM from interrupt context. For power saving reasons we keep ASPM L1 enabled, but implement a heuristic to "quickly" disable ASPM L1 when we notice PCIe traffic (as measured by the interrupt rate) starting up. If interrupt activity ceases ASPM L1 is re-enabled. > Disabling ASPM should only require writing the device's Link Control > register. The PCI core could probably provide an interface to do that > in interrupt context. > > Enabling ASPM is not latency-critical and could probably be done from > a work queue outside interrupt context, although conceptually there > shouldn't be much required here either, and possibly the PCI core > interface could be improved. That is true, to keep latencies low we need to disable ASPM from interrupt context, but re-enabling ASPM is not latency critical. > It's possible the latency problem could be handled by some sort of > quirk that overrides the acceptable latency. Correct, this is another issue that needs to be resolved.