Received: by 10.223.185.116 with SMTP id b49csp7608919wrg; Thu, 1 Mar 2018 08:09:46 -0800 (PST) X-Google-Smtp-Source: AG47ELsKHVEI6UU1iBG8v/crhgUZuB4Q+wBfdZfEfZ1Ta2EE/Tm0HHXlVXkQGK9voOptpLDffbbe X-Received: by 10.99.165.71 with SMTP id r7mr1985446pgu.60.1519920586111; Thu, 01 Mar 2018 08:09:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519920586; cv=none; d=google.com; s=arc-20160816; b=nOuB7KVhT+rSBv3KHo1f6dF/aO0WXzXx35+U6Wh+YvWgYA+AN6VOUv412kAX16A7ih ZA5M0+wSi8BnyRHrez+w/nKswx9vf+KBvPwVg7tMx5wKcjix6W2gVsI8oc9d3DJEQhZ7 Kf2VedYXxTd7f4zEZ2knhEU5Q3/akf48Q3tEMNM2/nHgMbF3cOBIQo3q/ZF32IWyWC8v /I+gNDBs0soSlVsiqZ4DsCM6gW0wukhUDpZEG+2OpyxPYEzTRzciRs+hLsl+D1Db8rdJ olQQuhDlt5ssldZvnamLEpvC8VyIn0v8WEswSS8pQzgEdcTGTsfB04dfM5XKh8lWz9ti Tcdw== 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:arc-authentication-results; bh=x4BvFhVTeYEKU1sw7QaXvESvHnwJSo+LJvpy3rg2R2c=; b=cl7oOKhoPw6cQbnSXRGnUZ36c7jPoaqWj5lMIxDHYnIHlYC2DH4ZYRqvrBSEKtgI5T 4HNjl+WjM4dnO2F5b0eeQWbvPstzf6SKvkUH/NtI+VCKZcb5vYL+pegleVVmCv954IC8 Tu8kyZ79WsViKlh4RMW+E6aAZGKTLAk4JNBczGkqYplfYvswX7QY2vWEo59w93gJf4pj ZecaDuFOjUa6dsRCyBc8pfPUrc5btIWsziG/r34PBxiXj9JP3Ca9vPj1cWKxkH43Bsu0 tOhGrFXa3j4FtEf+Nfh2+qKuoT0aOhckwbfrTzqKWwXrQ7ljt5J5uFjxojJSfSpTV/xM ykng== 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 f6si2627690pgn.165.2018.03.01.08.09.30; Thu, 01 Mar 2018 08:09:46 -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 S1032826AbeCAQIr (ORCPT + 99 others); Thu, 1 Mar 2018 11:08:47 -0500 Received: from mga12.intel.com ([192.55.52.136]:53500 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031777AbeCAQIq (ORCPT ); Thu, 1 Mar 2018 11:08:46 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2018 08:08:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,408,1515484800"; d="scan'208";a="33890401" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga004.fm.intel.com with ESMTP; 01 Mar 2018 08:08:44 -0800 Date: Thu, 1 Mar 2018 09:10:42 -0700 From: Keith Busch To: Ming Lei Cc: Christoph Hellwig , Jianchao Wang , axboe@fb.com, sagi@grimberg.me, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH V2] nvme-pci: assign separate irq vectors for adminq and ioq0 Message-ID: <20180301161042.GA14799@localhost.localdomain> References: <1519832921-13915-1-git-send-email-jianchao.w.wang@oracle.com> <20180228164726.GB16536@lst.de> <20180301150329.GB6795@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180301150329.GB6795@ming.t460p> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 01, 2018 at 11:03:30PM +0800, Ming Lei wrote: > If all CPUs for the 1st IRQ vector of admin queue are offline, then I > guess NVMe can't work any more. Yikes, with respect to admin commands, it appears you're right if your system allows offlining CPU0. > So looks it is a good idea to make admin queue's IRQ vector assigned as > non-managed IRQs. It'd still be considered managed even if it's a 'pre_vector', though it would get the default mask with all possible CPUs.