Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp608563ybi; Tue, 16 Jul 2019 02:33:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzO8kLFwyYIfH+Py4lvR13abD7JQZxKad8Fhf5hYnNhqS1P81Vs9a44liAdbzr2YbSOrL7 X-Received: by 2002:a63:4d50:: with SMTP id n16mr32556753pgl.146.1563269636176; Tue, 16 Jul 2019 02:33:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563269636; cv=none; d=google.com; s=arc-20160816; b=DVvIynkTWZQFgOsE6E+2GOY9NE+BWIJduYetD28nNQGMzJedaCkipP2g1JxHEm5I3e pQKPqqNCbUJqOkJWLF8+jghQBKmh2CJM/xMRZHtQxQDPQuapXwy6082lcASX/7LvSXWS wNbt9UPA4ROmXekWDisr/jPRt8P9Lnuj90EOFmTbY///0ZNgV9P8rjPjFYYRA08HE4U8 qqMnXd8JSvQSYWzxszRWB29qCQJB/UvXDIY0HrVrbYVoEi5aj5lJU2qz6PFxrsZHeRjd kZWjgfUXj7okyQeqE191cnTNUoy8ndiPxYxx7UqbDKzgf2v0HyiyDHfJta0rzF9O7nPh B3qA== 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=EZDHR+7sUK1WPju0UTksBY03TC6DrxyLeSTHAMpQC2Y=; b=B4TbCLxxeW1mEJBT3YOa1mgPh6us58NgjNz0KNA13AmlzNluwSgXmpxDlgMSBtGM8E SPBCOPbupMHhm8F57GVVHAd0WKoFcnmhca89pFrU9zf17Sei/CDJSNorDCasGx0HeK+m bxX65VMblJAytneHs7+iSwYdOWD6+eVxdrFjp8wDVyhW/cBcHxPN6k6jM/e4laLUW0IK Xjh+TCClamxWE8BtL2bEnnOdT5QfYYKt7VrdMBlHm0RbQwXs5j2vgidbvZYUPcQn7mYr F6zXaTzkYlGFX8UxHoAks2+DZxYwsmRz2PaG0zOg3mK/N9r98NnTkocGRnvYaelKdeoV AQSQ== 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 z4si17149298plk.364.2019.07.16.02.33.39; Tue, 16 Jul 2019 02:33:56 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731391AbfGPJdE (ORCPT + 99 others); Tue, 16 Jul 2019 05:33:04 -0400 Received: from verein.lst.de ([213.95.11.211]:40185 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726997AbfGPJdE (ORCPT ); Tue, 16 Jul 2019 05:33:04 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 3360468B05; Tue, 16 Jul 2019 11:33:02 +0200 (CEST) Date: Tue, 16 Jul 2019 11:33:01 +0200 From: Christoph Hellwig To: Benjamin Herrenschmidt Cc: Christoph Hellwig , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Jens Axboe , Keith Busch , Paul Pawlowski Subject: Re: [PATCH 2/3] nvme: Retrieve the required IO queue entry size from the controller Message-ID: <20190716093301.GA32562@lst.de> References: <20190716004649.17799-1-benh@kernel.crashing.org> <20190716004649.17799-2-benh@kernel.crashing.org> <20190716060430.GB29414@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 16, 2019 at 04:21:14PM +1000, Benjamin Herrenschmidt wrote: > > Actually, this doesn't work on a "real" nvme controller, to change CC > > values the controller needs to be disabled. > > Not really. The specs says that MPS, AMD and CSS need to be set before > enabling, but IOCQES and IOSQES can be modified later as long as there > is no IO queue created yet. I guess that is true based on the spec. > This is necessary otherwise there's a chicken and egg problem. You need > the admin queue to do the controller id in order to get the sizes and > for that you need the controller to be enabled. > > Note: This is not a huge issue anyway since I only update the register > if the required size isn't 6 which is probably never going to be the > case on non-Apple HW. Yes, but the whole point of making you go down the route is so that we can share the code with eventual real nvme controllers that can support a larger SQE size. > > So back to the version > > you circulated to me in private mail that just sets q->sqes and has a > > comment that this is magic for The Apple controller. If/when we get > > standardized large SQE support we'll need to discover that earlier or > > do a disable/enable dance. Sorry for misleading you down this road and > > creating the extra work. > > I think it's still ok, let me know... Ok, let's go with this series then unless the other maintainers have objections. I'm still not sure if we want to queue this up for 5.3 (new hardware enablement) or wait a bit, though.