Received: by 10.223.185.116 with SMTP id b49csp6350075wrg; Wed, 28 Feb 2018 08:01:16 -0800 (PST) X-Google-Smtp-Source: AH8x227oWbboeA2Gy8V9QYKqt7o4SanFOiXVYQ3E3lbUEhKGw0buzgjt5WkdrnqswPdbCotSbNnq X-Received: by 10.99.96.66 with SMTP id u63mr14931760pgb.49.1519833675867; Wed, 28 Feb 2018 08:01:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519833675; cv=none; d=google.com; s=arc-20160816; b=oivEjYYmp04205EfQt/TLm+gjRqFhIs72UUqv2orFyyHJDCB0huiuF6nOuFr7PZMql 2QT6mRVcx2MQic/eEartAtn8tcSd+AoJvsnC1WBTRPkAY3hKS8SRKmzNEGf/6DjiMvdZ 6xsoThQnSh47Hu+oB8r96CRg9s5ZLyAtuDMLS8DoJCn/6RKGKb3zGNu8yJ/saWrldE4w 2R6IZF1rfXCQ+P8ateqLud/M4Zf7mn4YfZnhp194J3DP4zgWmwtDm802a+Nl8UUaGDW1 mg2qvnChvFdYtvzUx274WKEFjqEHlXTg42Q3LmDVLT47pT9bp2IVFOfaI76AmC/yZ41t jDiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=WIh8uuQEM7oKAB9dYWdT7VkncezizpMpkNWohPNRObI=; b=OQ6u9t2ySIOmUhu+JHP9U0hR1nV9/K3V+ZeEBYfqgGWcMuNXiTBud0KGaz9cSli+jI LFtmFBkaCFU5HS1EEa0/LCVuyxZqzqsjhD0S1JpKll7K0UHE8d3i400mr3LMaAwk0c7s iRFg33uxMbZlMcsakrX2f50GZOzdsjXbMePEMxJ6jhK/rPFhh7UjHFeRJxfFfM71Rk06 D/hm3gVpozFBBnjtlExZpGHJ2IoyFUIbEaxEhttftqniTKG8+QzR2zq9MJ5tj9PqAYVL 0BxaTw4cxm6uQmOSw0DpeUnO76C7Ocwil6scNw3MXYI2MPCubWWrZzS/RvLyL6g90F4x IyJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=loewLUN6; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p9si1140693pgc.685.2018.02.28.08.00.53; Wed, 28 Feb 2018 08:01:15 -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=@gmail.com header.s=20161025 header.b=loewLUN6; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752891AbeB1QAC (ORCPT + 99 others); Wed, 28 Feb 2018 11:00:02 -0500 Received: from mail-qt0-f174.google.com ([209.85.216.174]:38360 "EHLO mail-qt0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932164AbeB1P7z (ORCPT ); Wed, 28 Feb 2018 10:59:55 -0500 Received: by mail-qt0-f174.google.com with SMTP id n12so3555799qtl.5 for ; Wed, 28 Feb 2018 07:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WIh8uuQEM7oKAB9dYWdT7VkncezizpMpkNWohPNRObI=; b=loewLUN6RmzQjTGL8Kh679Jk018uR4SZwrV6gJ4PvUiuGaNkRm4A6FK8VjkKnXosXs 0Yi0CAhNAn4WNavcVQSNzaXRcr7gGqEKxL5SBMc0OgJ01Zp9A6TmukrYj0yW9nijwhz4 AIMh8Vgs/zPIfvkd+ChYG0WiTV24DLQF5i0Ds3teGFUgvNIFA6bYjh5h15EctNRKgnyX AEPCeUyrfZ9ltsWeIPUsoAzLsOUxG/Rmz8/avEtFfyEOF5XAGW+W0gozzkK5wGAPRsRR Y2j3IS+fdzcxMUEBg5pCiC+NM415b775Bx1i1DZdEM4h389GJXHFtiiU/kll9m1FGY2P EieQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WIh8uuQEM7oKAB9dYWdT7VkncezizpMpkNWohPNRObI=; b=Y2e1wiWYgrKtWSE7nu9DGMeCZeMu4yURmmNXflpAgpgWlk6YsiU9Af7EMesGevpNkq kb7LRrCU4dIxFurRXA9g1YjZaNraEnIVk41kFhm+KJEsf/ZJZ6JitmX6LkQIZ6D8r3np qmrjXzIicIHQQ/jnXkDHDEpTvEjBtlppKMXawyw5VkrYPi6HUt2+mxt33tNcyjFi7huR 44rZpUuy1ImMkwWz5T2UFAsZ6K1BjNDlVWoiDUc7pS5TSwqqXHf3/bYjTt6wz8K+zepg M8V/lQ2crNOaeUT9IJ8T8B6tulmlA5OySqcO+SrXPRyR52mSDNm7FoXpNtq7eacWqBu5 /tdQ== X-Gm-Message-State: APf1xPDavTALXptG43NWrjHGF34FhUBNIJhlpoeiegS6FIhYksIrQ+3M 5kdaMhqoBAbf2J2YuM2G8rfWBCcxahKbKk40AdWtxLXEJIM= X-Received: by 10.237.59.232 with SMTP id s37mr29335942qte.83.1519833595079; Wed, 28 Feb 2018 07:59:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.195.80 with HTTP; Wed, 28 Feb 2018 07:59:54 -0800 (PST) In-Reply-To: <1519832921-13915-1-git-send-email-jianchao.w.wang@oracle.com> References: <1519832921-13915-1-git-send-email-jianchao.w.wang@oracle.com> From: Andy Shevchenko Date: Wed, 28 Feb 2018 17:59:54 +0200 Message-ID: Subject: Re: [PATCH V2] nvme-pci: assign separate irq vectors for adminq and ioq0 To: Jianchao Wang Cc: Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Linux NVMe Mailinglist , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 28, 2018 at 5:48 PM, Jianchao Wang wrote: > Currently, adminq and ioq0 share the same irq vector. This is > unfair for both amdinq and ioq0. > - For adminq, its completion irq has to be bound on cpu0. It > just has only one hw queue, it is unreasonable to do this. > - For ioq0, when the irq fires for io completion, the adminq irq > action on this irq vector will introduce an uncached access on > adminq cqe at least, even worse when adminq is busy. > > To improve this, allocate separate irq vectors for adminq and > ioq0, and not set irq affinity for adminq one. If just one irq > vector, setup adminq + 1 ioq and let them share it. In addition > add new helper interface nvme_ioq_vector to get ioq vector. > +static inline unsigned int nvme_ioq_vector(struct nvme_dev *dev, > + unsigned int qid) > +{ > + /* > + * If controller has only legacy or single-message MSI, there will > + * be only 1 irq vector. At the moment, we setup adminq + 1 ioq > + * and let them share irq vector. > + */ > + return (dev->num_vecs == 1) ? 0 : qid; Redundant parens. > +} > > for (i = dev->ctrl.queue_count; i <= dev->max_qid; i++) { > - /* vector == qid - 1, match nvme_create_queue */ > if (nvme_alloc_queue(dev, i, dev->q_depth, > - pci_irq_get_node(to_pci_dev(dev->dev), i - 1))) { > + pci_irq_get_node(to_pci_dev(dev->dev), > + nvme_ioq_vector(dev, i)))) { Perhaps better to introduce a temporary variable to make it readable? > ret = -ENOMEM; > break; > } > + ret = pci_alloc_irq_vectors_affinity(pdev, 1, (nr_io_queues + 1), > + PCI_IRQ_ALL_TYPES | PCI_IRQ_AFFINITY, &affd); > + if (ret <= 0) > return -EIO; > - dev->max_qid = nr_io_queues; > - > + dev->num_vecs = ret; > + dev->max_qid = (ret > 1) ? (ret - 1) : 1; I don not see how ret can possible be < 1 here. Thus, the logic looks like this: if ret >= 2 => return ret - 1; // Possible variants [1..ret - 1] if ret == 1 => return 1; So, for ret == 1 or ret == 2 we still use 1. Is it by design? Can it be written like dev->max_qid = max(ret - 1, 1); -- With Best Regards, Andy Shevchenko