Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4398866yba; Wed, 17 Apr 2019 10:35:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1mS6xR1k8UbKwfiaq0SN6Sj8XS+Mb2noC6DKNS3RGjBqQlLy4kRxLB5kIkWodBccxFenu X-Received: by 2002:a65:64cf:: with SMTP id t15mr81607969pgv.322.1555522558464; Wed, 17 Apr 2019 10:35:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555522558; cv=none; d=google.com; s=arc-20160816; b=nJ7pU4hobuFHCEuv4r/xru4upJir52/TfR/EPFEjB0VLidbfykai27IyTLUQbOWZnp IUXCSFVitc4su4CFvO1TRI1dAnmdVAiZZ7448Io1da5XfJLK7c1YtcGHqNFqz7JOOYeU uausp3RI6xTkbp9RPQO11rtna5vPrx2J72m4nYWVGWRLQNcz4rXAHXLQaNk+dstYFwof MFBifKVymbPKrQ3D4uyHfOu+fYVIzE+BPLBV1+i0ZQQKK6P/Thc8Dd4yLO37ZyyNDpxM eSkCWsmM8TDqTvZ5NFdS4YfbCD05+6lRL7xW1HqA2Sfrv7k/QZfcP1+y+wq4UB1maZgu bsAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:to:from:subject:message-id; bh=Sq+ZFfhnWt3OLqU+2vfLG4LVzbOpsD7t+s1YYwzy5Z8=; b=Pwu+dIt+FNfHamMc8OOse+4URCgXmVsVjCq52Bvt1FRZVASlz2e8DSerREVtpEllNs D2nMZhqzcauelMKqacp9Lh6UQRVtLIVSxrwhU2PpTwLbon0wJQfWhd1sax2Ds5hnCzll N07BBY487hnVPLZzvLpZeNQqdjGZ7JrG5w839pdcUNH0Sz+w7bwOhVMQF9Zb3ziEWgbd Iq0rYDeM8XkeUbF28ifrg9QyR+1KLi2GhGCAbLE1EbdofbFcd1zgv/OZ1av+4kIyjd6i p04zl21fwrDPigH1TjvUeRrvRehLfpD4GNPwqeDkyuzUpV8C3OERBQPJJszwQ9zpNWDq JDBw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y6si56032318pfb.269.2019.04.17.10.35.43; Wed, 17 Apr 2019 10:35:58 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732989AbfDQRdj (ORCPT + 99 others); Wed, 17 Apr 2019 13:33:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56033 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732321AbfDQRdj (ORCPT ); Wed, 17 Apr 2019 13:33:39 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 398BA307EA8F; Wed, 17 Apr 2019 17:33:39 +0000 (UTC) Received: from maximlenovopc.usersys.redhat.com (unknown [10.35.206.34]) by smtp.corp.redhat.com (Postfix) with ESMTP id B10F8608C1; Wed, 17 Apr 2019 17:33:37 +0000 (UTC) Message-ID: <096935354b16662eb481aeda1f48001ba489463c.camel@redhat.com> Subject: Re: [PATCH] nvme: determine the number of IO queues From: Maxim Levitsky To: Aaron Ma , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, keith.busch@intel.com, axboe@fb.com Date: Wed, 17 Apr 2019 20:33:36 +0300 In-Reply-To: References: <1555510379-20199-1-git-send-email-aaron.ma@canonical.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Wed, 17 Apr 2019 17:33:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-04-17 at 20:32 +0300, Maxim Levitsky wrote: > On Wed, 2019-04-17 at 22:12 +0800, Aaron Ma wrote: > > Some controllers support limited IO queues, when over set > > the number, it will return invalid field error. > > Then NVME will be removed by driver. > > > > Find the max number of IO queues that controller supports. > > When it still got invalid result, set 1 IO queue at least to > > bring NVME online. > > To be honest a spec compliant device should not need this. > The spec states: > > "Number of I/O Completion Queues Requested (NCQR): Indicates the number of I/O > Completion > Queues requested by software. This number does not include the Admin > Completion > Queue. A > minimum of one queue shall be requested, reflecting that the minimum support > is > for one I/O > Completion Queue. This is a 0’s based value. The maximum value that may be > specified is 65,534 > (i.e., 65,535 I/O Completion Queues). If the value specified is 65,535, the > controller should return > an error of Invalid Field in Command." > > > This implies that you can ask for any value and the controller must not > respond > with an error, but rather indicate how many queues it supports. > > Maybe its better to add a quirk for the broken device, which needs this? I forgot to add the relevant paragraph: "Note: The value allocated may be smaller or larger than the number of queues requested, often in virtualized implementations. The controller may not have as many queues to allocate as are requested. Alternatively, the controller may have an allocation unit of queues (e.g. power of two) and may supply more queues to host software to satisfy its allocation unit." Best regards, Maxim Levitsky