From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device Date: Fri, 1 Aug 2014 15:16:26 +0200 Message-ID: <201408011516.26253.arnd@arndb.de> References: <1406344128-27055-1-git-send-email-wangyijing@huawei.com> <53D89502.60506@linux.intel.com> <53D89CA1.7000501@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53D89CA1.7000501@huawei.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Yijing Wang Cc: linux-arch@vger.kernel.org, Wuyun , Russell King , Paul.Mundt@huawei.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, "James E.J. Bottomley" , Xinwei Hu , Hanjun Guo , Bjorn Helgaas , virtualization@lists.linux-foundation.org, Jiang Liu , linux-arm-kernel@lists.infradead.org List-Id: linux-arch.vger.kernel.org On Wednesday 30 July 2014, Yijing Wang wrote: > >>> > >>> The other part I'm not completely sure about is how you want to > >>> have MSIs map into normal IRQ descriptors. At the moment, all > >>> MSI users are based on IRQ numbers, but this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you meaning. > >> What are the scalability problems you mentioned ? > > We have soft limitation of nr_irqs or hard limitation NR_IRQS, > > we couldn't allocate as much irq number as we need in some cases, > > such as to support MSI-x. > > Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ and the number of interrupts is not limited in any form. My point was more that the device driver should not need to care about the interrupt number: it gets made up on the spot when the MSI is needed, and then it is only used to request the IRQ. This can be simplified into one interface at the device driver level, even though the internal still use numbers somewhere. If we ever remove IRQ numbers from the driver API, this part doesn't need to get touched again. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de ([212.227.17.24]:58592 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754881AbaHANRY (ORCPT ); Fri, 1 Aug 2014 09:17:24 -0400 From: Arnd Bergmann Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device Date: Fri, 1 Aug 2014 15:16:26 +0200 References: <1406344128-27055-1-git-send-email-wangyijing@huawei.com> <53D89502.60506@linux.intel.com> <53D89CA1.7000501@huawei.com> In-Reply-To: <53D89CA1.7000501@huawei.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <201408011516.26253.arnd@arndb.de> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Yijing Wang Cc: Jiang Liu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Russell King , Paul.Mundt@huawei.com, Marc Zyngier , linux-pci@vger.kernel.org, "James E.J. Bottomley" , virtualization@lists.linux-foundation.org, Xinwei Hu , Hanjun Guo , Bjorn Helgaas , Wuyun Message-ID: <20140801131626.o3m3ys-VWDgwRb1OSmcm7EsQdL__WqqZBFoDyM9PxTE@z> On Wednesday 30 July 2014, Yijing Wang wrote: > >>> > >>> The other part I'm not completely sure about is how you want to > >>> have MSIs map into normal IRQ descriptors. At the moment, all > >>> MSI users are based on IRQ numbers, but this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you meaning. > >> What are the scalability problems you mentioned ? > > We have soft limitation of nr_irqs or hard limitation NR_IRQS, > > we couldn't allocate as much irq number as we need in some cases, > > such as to support MSI-x. > > Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ and the number of interrupts is not limited in any form. My point was more that the device driver should not need to care about the interrupt number: it gets made up on the spot when the MSI is needed, and then it is only used to request the IRQ. This can be simplified into one interface at the device driver level, even though the internal still use numbers somewhere. If we ever remove IRQ numbers from the driver API, this part doesn't need to get touched again. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 1 Aug 2014 15:16:26 +0200 Subject: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device In-Reply-To: <53D89CA1.7000501@huawei.com> References: <1406344128-27055-1-git-send-email-wangyijing@huawei.com> <53D89502.60506@linux.intel.com> <53D89CA1.7000501@huawei.com> Message-ID: <201408011516.26253.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wednesday 30 July 2014, Yijing Wang wrote: > >>> > >>> The other part I'm not completely sure about is how you want to > >>> have MSIs map into normal IRQ descriptors. At the moment, all > >>> MSI users are based on IRQ numbers, but this has known scalability problems. > >> > >> Hmmm, I still use the IRQ number to map the MSIs to IRQ description. > >> I'm sorry, I don't understand you meaning. > >> What are the scalability problems you mentioned ? > > We have soft limitation of nr_irqs or hard limitation NR_IRQS, > > we couldn't allocate as much irq number as we need in some cases, > > such as to support MSI-x. > > Oh, yes, this is a potential issue. Gerry, thanks for you explanation. :) This should no longer be an issue, as arm64 uses CONFIG_SPARSE_IRQ and the number of interrupts is not limited in any form. My point was more that the device driver should not need to care about the interrupt number: it gets made up on the spot when the MSI is needed, and then it is only used to request the IRQ. This can be simplified into one interface at the device driver level, even though the internal still use numbers somewhere. If we ever remove IRQ numbers from the driver API, this part doesn't need to get touched again. Arnd