From mboxrd@z Thu Jan 1 00:00:00 1970 From: kbusch@kernel.org (Keith Busch) Date: Thu, 18 Apr 2019 07:48:21 -0600 Subject: [PATCH] nvme: determine the number of IO queues In-Reply-To: References: <1555510379-20199-1-git-send-email-aaron.ma@canonical.com> <096935354b16662eb481aeda1f48001ba489463c.camel@redhat.com> Message-ID: <20190418134820.GA7589@localhost.localdomain> On Thu, Apr 18, 2019@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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 168D4C10F0E for ; Thu, 18 Apr 2019 13:54:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D8CE4218A6 for ; Thu, 18 Apr 2019 13:54:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555595677; bh=TCI8DWIVeimx2GuVy+tLCe2905j5in1mN4GG2jy7FIc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=sM5gjwnJC9C1J683pqvLsqUrm5DMBEGySpegeeeAGaMtOifVYvKuYvR13Ff/R8TmU KJ7RWAzSOJJWX3cznvD6xsda8uJh2AHTV0F3Mn0dBWiXlXGz9MkYMmYhXOFQdhDOkY RSvLklRWg+uQtC0puxPJnX9KNbDVNxTisv6y7bhA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389134AbfDRNyg (ORCPT ); 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.