Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp254065imj; Wed, 13 Feb 2019 07:49:32 -0800 (PST) X-Google-Smtp-Source: AHgI3IYIMx1MGFa8eQ04Y25/H3dDZ5pZbqKogHoqumHBHvPyK0jjg1IrLhhJjgq9O1euSjLGNE/2 X-Received: by 2002:a62:76d4:: with SMTP id r203mr1131757pfc.15.1550072972243; Wed, 13 Feb 2019 07:49:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550072972; cv=none; d=google.com; s=arc-20160816; b=qHOgrP3Ljn6+LC1ICcBNUIvSRKk6eBdLJ1xLoXorHRE1fYfYyjXV/+OfexuFmWf6Bi S7dSRbm+HPkjW528sxRr0kvCWz5n60lq9f6MIqFAJwt2WRKW4gHCbUH4OdtBSOf0ke0B cX/lyk8ER2pH/uo1NX5lQHIZubf9zjtcPMRwzniHKWhPC0G3IAskbLs2W6ly1iiIGXFQ 5M3CP7e3lA4CtF+PbWBqxz7c4Zb+VvguRZekr+t/YbMpuKcMbAmDx2qhPOsSg/bKB1lw Rm1Nb4fb91OkYszxMUXGS7+NX5qsUGf9Y3m2KRxA7Jz5mcQsmsNntJr3HrDEDHoiLT8T l3Kw== 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; bh=3VZvY2Wt/iVCdF0rgplQF8gvgXYUKI1tqSIgauCoAxE=; b=HdRUL+KP3Sj0ZsOBcGuMlGMFjvJsF/Z6aeCmTkjvQD++UJWXBURS//+upfvtOe5QGG 41s/f0SvairljGrZVhB2QrYXkHznA/5bY/tLURRGs/66JaGmwxJkQtUBPh4KF+BPF2vW OiFv7u32ZlmN7LsoCq9lpwnpmEmHSIj1pErrxN9UVpbfU3jWTL0CkbB8jELtZf0Kb3yu R3kCRX7f5CevvTvSPU2bA5eKfNk1ErnFYKQJcPQU+0iD1PNknE93pqB2meGeB7kHo9jo 3xnzrHRwXRojcs7orM+8WgHBE2JM+VrfCnd1Lsx/wgekP7VwSgws0ycTi06pNQ5WZbjx XRZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WIUfn27q; 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 l7si17366194plg.390.2019.02.13.07.49.14; Wed, 13 Feb 2019 07:49:32 -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; dkim=pass header.i=@kernel.org header.s=default header.b=WIUfn27q; 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 S2388280AbfBMPNn (ORCPT + 99 others); Wed, 13 Feb 2019 10:13:43 -0500 Received: from mail.kernel.org ([198.145.29.99]:59490 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729139AbfBMPNm (ORCPT ); Wed, 13 Feb 2019 10:13:42 -0500 Received: from localhost (173-25-63-173.client.mchsi.com [173.25.63.173]) (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 7B8C220835; Wed, 13 Feb 2019 15:13:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1550070820; bh=6jRo9xVu8JdFnU+zOlf9IBsSFSRq1sbM9Zq4v0wDlds=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WIUfn27q9rHwln/4hnA4c0Hy1RJPbTQoSD7YmwUF2uY4pVmEHO1SLzNfgIBxOQMUo 5qP/PyrN90QvJg3U/mWrho2Bk22v49dKl6RrbnSv/FlXh7skkCrteX5JQ2SO/CSxhW nUMM6RFNLD8qWwVqwoc1iLJqNx1VddmoVxcVkegk= Date: Wed, 13 Feb 2019 09:13:39 -0600 From: Bjorn Helgaas To: Ming Lei Cc: Christoph Hellwig , Thomas Gleixner , Jens Axboe , linux-block@vger.kernel.org, Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Keith Busch Subject: Re: [PATCH V3 4/5] nvme-pci: avoid irq allocation retrying via .calc_sets Message-ID: <20190213151339.GE96272@google.com> References: <20190213105041.13537-1-ming.lei@redhat.com> <20190213105041.13537-5-ming.lei@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190213105041.13537-5-ming.lei@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 13, 2019 at 06:50:40PM +0800, Ming Lei wrote: > Currently pre-caculate each set vectors, and this way requires same > 'max_vecs' and 'min_vecs' passed to pci_alloc_irq_vectors_affinity(), > then nvme_setup_irqs() has to retry in case of allocation failure. s/pre-caculate/precalculate/ My usual "set vectors" question as on other patches. > This usage & interface is a bit awkward because the retry should have > been avoided by providing one reasonable 'min_vecs'. > > Implement the callback of .calc_sets, so that pci_alloc_irq_vectors_affinity() > can calculate each set's vector after IRQ vectors is allocated and > before spread IRQ, then NVMe's retry in case of irq allocation failure > can be removed. s/irq/IRQ/ > Reviewed-by: Keith Busch > Signed-off-by: Ming Lei > --- > drivers/nvme/host/pci.c | 62 +++++++++++++------------------------------------ > 1 file changed, 16 insertions(+), 46 deletions(-) > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c > index 0086bdf80ea1..8c51252a897e 100644 > --- a/drivers/nvme/host/pci.c > +++ b/drivers/nvme/host/pci.c > @@ -2078,14 +2078,25 @@ static void nvme_calc_io_queues(struct nvme_dev *dev, unsigned int irq_queues) > } > } > > +static void nvme_calc_irq_sets(struct irq_affinity *affd, int nvecs) > +{ > + struct nvme_dev *dev = affd->priv; > + > + nvme_calc_io_queues(dev, nvecs); > + > + affd->set_vectors[HCTX_TYPE_DEFAULT] = dev->io_queues[HCTX_TYPE_DEFAULT]; > + affd->set_vectors[HCTX_TYPE_READ] = dev->io_queues[HCTX_TYPE_READ]; > + affd->nr_sets = 2; > +} > + > static int nvme_setup_irqs(struct nvme_dev *dev, unsigned int nr_io_queues) > { > struct pci_dev *pdev = to_pci_dev(dev->dev); > struct irq_affinity affd = { > .pre_vectors = 1, > - .nr_sets = 2, > + .calc_sets = nvme_calc_irq_sets, > + .priv = dev, > }; > - int *irq_sets = affd.set_vectors; > int result = 0; > unsigned int irq_queues, this_p_queues; > > @@ -2102,50 +2113,8 @@ static int nvme_setup_irqs(struct nvme_dev *dev, unsigned int nr_io_queues) > } > dev->io_queues[HCTX_TYPE_POLL] = this_p_queues; > > - /* > - * For irq sets, we have to ask for minvec == maxvec. This passes > - * any reduction back to us, so we can adjust our queue counts and > - * IRQ vector needs. > - */ > - do { > - nvme_calc_io_queues(dev, irq_queues); > - irq_sets[0] = dev->io_queues[HCTX_TYPE_DEFAULT]; > - irq_sets[1] = dev->io_queues[HCTX_TYPE_READ]; > - if (!irq_sets[1]) > - affd.nr_sets = 1; > - > - /* > - * If we got a failure and we're down to asking for just > - * 1 + 1 queues, just ask for a single vector. We'll share > - * that between the single IO queue and the admin queue. > - * Otherwise, we assign one independent vector to admin queue. > - */ > - if (irq_queues > 1) > - irq_queues = irq_sets[0] + irq_sets[1] + 1; > - > - result = pci_alloc_irq_vectors_affinity(pdev, irq_queues, > - irq_queues, > - PCI_IRQ_ALL_TYPES | PCI_IRQ_AFFINITY, &affd); > - > - /* > - * Need to reduce our vec counts. If we get ENOSPC, the > - * platform should support mulitple vecs, we just need > - * to decrease our ask. If we get EINVAL, the platform > - * likely does not. Back down to ask for just one vector. > - */ > - if (result == -ENOSPC) { > - irq_queues--; > - if (!irq_queues) > - return result; > - continue; > - } else if (result == -EINVAL) { > - irq_queues = 1; > - continue; > - } else if (result <= 0) > - return -EIO; > - break; > - } while (1); > - > + result = pci_alloc_irq_vectors_affinity(pdev, 1, irq_queues, > + PCI_IRQ_ALL_TYPES | PCI_IRQ_AFFINITY, &affd); > return result; > } > > @@ -3021,6 +2990,7 @@ static struct pci_driver nvme_driver = { > > static int __init nvme_init(void) > { > + BUILD_BUG_ON(2 > IRQ_MAX_SETS); "IRQ_MAX_SETS < 2" would read more naturally; is there a reason to have it reversed? > return pci_register_driver(&nvme_driver); > } > > -- > 2.9.5 >