Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp616810yba; Thu, 18 Apr 2019 06:56:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqzOpB+y/jjQvuNnZYMmmFY9+qoTwflTNJZmG4tS43nemg22ERvEVvvRWXeIXkGikbe79rX5 X-Received: by 2002:a62:4e86:: with SMTP id c128mr96018306pfb.39.1555595764249; Thu, 18 Apr 2019 06:56:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555595764; cv=none; d=google.com; s=arc-20160816; b=nKAjdyEglUtztLvNpm97b7udcwlCfVf8GleeJ2fAniRBRuRiUpFlvTIcp9kp7qp4J5 AzdUxNT4D5DkXN+1KecGcMgygN3e/McixkD18PuwYj4bcxI9A1j9ABsCLYx7WW2qJm50 RhinyM/6stt1dm+8rkKGmbt/RlcvRS3IR4iphpB+ECuAuu2jdZyzzVQ9gI2gqZXFIYSv jqfLm9fQ3gGey9NyJsUYu6AtRQFRucrKNd5qz4NEF6dppqs1kuh1e/uTG0j0cAMfJuoy eZv4AzVAfELW7a6/7ghTwgfy/hYfVlGYM6buNv9jqH2lF2TQl1p4EbwJLySQpAgObhDx DYUw== 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; bh=zWF8dz2xtA9W8URSq0065c9mlcXwvYffnPR5elutTyM=; b=gPfu/fOAbPovegOCI1V9VmsxHfFBlN+LYHiiQVCaFGrWjvmYIjSRrBXnH1S4jBfXiR 0SCBTT4TPqHlnPai0O/QANRyY5zBIicz9auT/DyXTVAb/PujCD7F6EqzNnXWtWvkv833 k5dGLUK9VqgFOHUfqjIx17vJrU7elZnoY3IaOBPI90NwnDT/twg+PKzXgpkD+e8L0ACM DsDX9hI9U1wa2ErGjAF1YjoGBEAoBMGQXmo+yG/3tVeNCOeKho8I0JyIRSyWnihUhicM dyrm1Zp65/LdRVEBntPc4oOZmCH/ELjiC7SUHVjVYtcZ2cJBvrhsoEwfsiDpgYDR5tUi CA3w== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i70si2320185pfj.236.2019.04.18.06.55.49; Thu, 18 Apr 2019 06:56:04 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389103AbfDRNyg (ORCPT + 99 others); Thu, 18 Apr 2019 09:54:36 -0400 Received: from mga17.intel.com ([192.55.52.151]:7158 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728074AbfDRNyg (ORCPT ); Thu, 18 Apr 2019 09:54:36 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2019 06:54:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,366,1549958400"; d="scan'208";a="317020806" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by orsmga005.jf.intel.com with ESMTP; 18 Apr 2019 06:54:34 -0700 Date: Thu, 18 Apr 2019 07:48:21 -0600 From: Keith Busch To: Aaron Ma Cc: Maxim Levitsky , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, keith.busch@intel.com, axboe@fb.com Subject: Re: [PATCH] nvme: determine the number of IO queues Message-ID: <20190418134820.GA7589@localhost.localdomain> References: <1555510379-20199-1-git-send-email-aaron.ma@canonical.com> <096935354b16662eb481aeda1f48001ba489463c.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Apr 18, 2019 at 02:21:57PM +0800, Aaron Ma wrote: > On 4/18/19 1:33 AM, Maxim Levitsky wrote: > >> > >> Maybe its better to add a quirk for the broken device, which needs this? > > Adding quirk only makes the code more complicated. > This patch doesn't change the default behavior. > Only handle the NVME error code. It does change the default behavior. If I have a degraded controller that can't do IO in a machine with 1000's of CPUs, I have to iterate this non-standard behavior 1000's of times before the drive is servicable again. We currenlty figure that out in just a single try. At least the quirks document *why* the driver is doing non-standard behavior. We do the IO queue quirks for Macbooks, for example. But why don't you file a bug report with the device vendor instead? Surely a firmware fix provides the best possible outcome, and would make this device work not only in all versions of Linux, but also every standard compliant driver for any OS.