Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp859730imj; Fri, 15 Feb 2019 08:00:43 -0800 (PST) X-Google-Smtp-Source: AHgI3IbYaBhHBQ2Z2EDTED3LPeDtBxLmeK0grKerREMujcYeLM4GQ/mE1bZk4qFgi0XeuBjq2Dag X-Received: by 2002:a17:902:b494:: with SMTP id y20mr11180406plr.178.1550246443657; Fri, 15 Feb 2019 08:00:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550246443; cv=none; d=google.com; s=arc-20160816; b=RRn3TMDqTuJKBFuh+59B81QS64nQvveHVEilJmKqvr9q9/CKtRXKiEdz8wvxvwmqAX Cu5tRogSJzccKd5wc8r+I76+0rBS7wmXIOf/GyWoRFdxcPAPkI+uRIePhSfMoKD7wyeN Pr4bnY62zWSB6VC9dMDM9rDa5O3qyddvgClzqoEcewoTa8ejd4cLG41TMYUSrvlqrCkn lcT8XDcLNo+2QmDmszT1vv8K6/5TscAs+CDJ5JLoBK571BbdWC59zHa/zkWwWCKyChwe eFoTVbchPO/XTgSrMcmc+5OV8r4ZB2/kexT5Bd53Zljtl4yjNHn+8rDfOBWN1BpNP6GT y+sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=IXDeO4yCg6j6ha3GyPME9DAAgDdlKGvryrUstaK40eI=; b=Ew8XqA+/oFAAzH5jQciuVleD2rB9kok8VwFAMIicmOGYilrSX439oDmgXTi+3oWN9h DBUjM4HhJ+B/6zhrBBYNOWkY88EWNyMorty5vexhsrB/9ga6+OWyamtvJis14fj4yWif 2WBEOzPmfTYn3YSJKEIg4CGy0lil5ReK9EeDtb7tT1c03zyqMrfzmgpThKx6gWlpVA72 8H5qcUh6eS1itDow0RQs3h9kufUgRQsLda/RpocBuStwbHEnV6JfJ0sHsxzvAdQiTOwM tlWSUmaQ1awvC0UVk6wafrfLTozoVW3Ywtsw1rOzaZQjBxAAfvCiIIbl3/UxPy5BAsjq Fnhg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y14si4241681plr.78.2019.02.15.08.00.27; Fri, 15 Feb 2019 08:00:43 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732913AbfBOJxH (ORCPT + 99 others); Fri, 15 Feb 2019 04:53:07 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:52191 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730379AbfBOJxH (ORCPT ); Fri, 15 Feb 2019 04:53:07 -0500 Received: from p5492e0d8.dip0.t-ipconnect.de ([84.146.224.216] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1guaAu-0007vQ-4W; Fri, 15 Feb 2019 10:52:52 +0100 Date: Fri, 15 Feb 2019 10:52:51 +0100 (CET) From: Thomas Gleixner To: Marc Zyngier cc: LKML , Ming Lei , Christoph Hellwig , Bjorn Helgaas , Jens Axboe , linux-block@vger.kernel.org, Sagi Grimberg , linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, Keith Busch , Sumit Saxena , Kashyap Desai , Shivasharan Srikanteshwara Subject: Re: [patch V5 4/8] nvme-pci: Simplify interrupt allocation In-Reply-To: <868syhs8tn.wl-marc.zyngier@arm.com> Message-ID: References: <20190214204755.819014197@linutronix.de> <20190214211759.699390983@linutronix.de> <868syhs8tn.wl-marc.zyngier@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Feb 2019, Marc Zyngier wrote: > On Thu, 14 Feb 2019 20:47:59 +0000, > Thomas Gleixner wrote: > > drivers/nvme/host/pci.c | 108 ++++++++++++------------------------------------ > > 1 file changed, 28 insertions(+), 80 deletions(-) > > > > --- a/drivers/nvme/host/pci.c > > +++ b/drivers/nvme/host/pci.c > > @@ -2041,41 +2041,32 @@ static int nvme_setup_host_mem(struct nv > > return ret; > > } > > > > -/* irq_queues covers admin queue */ > > -static void nvme_calc_io_queues(struct nvme_dev *dev, unsigned int irq_queues) > > +/* > > + * nirqs is the number of interrupts available for write and read > > + * queues. The core already reserved an interrupt for the admin queue. > > + */ > > +static void nvme_calc_irq_sets(struct irq_affinity *affd, unsigned int nrirqs) > > { > > - unsigned int this_w_queues = write_queues; > > - > > - WARN_ON(!irq_queues); > > - > > - /* > > - * Setup read/write queue split, assign admin queue one independent > > - * irq vector if irq_queues is > 1. > > - */ > > - if (irq_queues <= 2) { > > - dev->io_queues[HCTX_TYPE_DEFAULT] = 1; > > - dev->io_queues[HCTX_TYPE_READ] = 0; > > - return; > > - } > > + struct nvme_dev *dev = affd->priv; > > + unsigned int nr_read_queues; > > > > /* > > - * If 'write_queues' is set, ensure it leaves room for at least > > - * one read queue and one admin queue > > - */ > > - if (this_w_queues >= irq_queues) > > - this_w_queues = irq_queues - 2; > > - > > - /* > > - * If 'write_queues' is set to zero, reads and writes will share > > - * a queue set. > > - */ > > - if (!this_w_queues) { > > - dev->io_queues[HCTX_TYPE_DEFAULT] = irq_queues - 1; > > - dev->io_queues[HCTX_TYPE_READ] = 0; > > - } else { > > - dev->io_queues[HCTX_TYPE_DEFAULT] = this_w_queues; > > - dev->io_queues[HCTX_TYPE_READ] = irq_queues - this_w_queues - 1; > > - } > > + * If only one interrupt is available, combine write and read > > + * queues. If 'write_queues' is set, ensure it leaves room for at > > + * least one read queue. > > [Full disclaimer: I only have had two coffees this morning, and it is > only at the fourth that my brain is able to kick in...] > > I don't know much about NVME, but I feel like there is a small > disconnect between the code and the above comment, which says "leave > room for at least one read queue"... > > > + */ > > + if (nrirqs == 1) > > + nr_read_queues = 0; > > + else if (write_queues >= nrirqs) > > + nr_read_queues = nrirqs - 1; > > ... while this seem to ensure that we carve out one write queue out of > the irq set. It looks like a departure from the original code, which > would set nr_read_queues to 1 in that particular case. Bah. right you are.