From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07D793E9299 for ; Thu, 21 May 2026 14:38:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779374313; cv=none; b=cz6YXX9DKC3KCuEEfNsSnpIj1owysW/1eK1EwR+DDA21/+NFRO1PLWfsP4qa+hRf/q4VRBvHo0B9kf/UCo0toairqZ9WXhuh2qJuKPFMiuT3pmtU1DZ0TQvGclYWKaOyvzMVAkTPDdsCXTNYLoJVuR9MUYa39DDA1n20QQw3hko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779374313; c=relaxed/simple; bh=6WIUTWkL9E7iND0Sgz3sf2EyOxBvRApzoacUlDq7A8g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u2+jDsQVHCT52WamTu/0VL9K4PhTvY8eOyn+w7fw4bjn+GiUfq+/3B6CGTnadMvMHw1EedGxw3cYcQq4Z5s6o/5hmu6ynkNusq6V/QpC1lwZaKofIpcWpcG8rkqXNt6HJB2+xn5Skh/gzs3xol6jJYVXrcTWPT8EmGf4SpC37tI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aFbDbYur; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aFbDbYur" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 630F31F000E9; Thu, 21 May 2026 14:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779374311; bh=qjko/TRE1WRRvwHvv6Gj+2tx1e0ugD9TDIucu1hV9mU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=aFbDbYurlY+sRAsCbGhWOWAdEXn6UJe3RrikivAxm1NP3H8mp2SWl2EYgH+FaJq24 p9Q8JMrH1jQT5SmVwrwfzIMukuX62353ZFoVqURCZnNS4/iy/DE/k/wXtifK6/tJVm xhdK6hWqoNBRpKvpQ6YUCk+pFEykjo0gCYU7uSqeIk1XR9enl1pGWs3B8HY+LO59Fn 67GRjcl4vGBs04mgMdAAejUm4Cp2zPdAjaGOOGx7DBlLsH+vjdNht7nmZIrQMs5Hl5 fbYTns7ClILh0c6E+I/BwDvtnvaKa1EV2Embiaq4Waq/a987hwbjPvvfgQXCjSjdwB 9S6J6Yu9O498w== Date: Thu, 21 May 2026 08:38:29 -0600 From: Keith Busch To: Christoph Hellwig Cc: Chao Shi , linux-nvme@lists.infradead.org, Sagi Grimberg , Jens Axboe , Tatsuya Sasaki , Maurizio Lombardi , linux-kernel@vger.kernel.org, Sungwoo Kim , Dave Tian , Weidong Zhu Subject: Re: [PATCH v2] nvme: reserve a keep-alive admin tag for all transports Message-ID: References: <20260515071248.2689513-1-coshi036@gmail.com> <20260521082549.GA11208@lst.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260521082549.GA11208@lst.de> On Thu, May 21, 2026 at 10:25:49AM +0200, Christoph Hellwig wrote: > On Wed, May 20, 2026 at 02:26:13PM -0600, Keith Busch wrote: > > I am skeptical anyone would produce a PCIe device that supports it, but > > let's say someone does: what is the use case motivating enabling this > > optional feature in this driver? If it's just because the option is > > there, then I think we can just reject the user command submitting the > > feature for PCIe transports, like I earlier suggested. Requiring an > > active command will just harm idle power states. > > I don't think that's quite the point. We'd have to add special > filtering to fix the reproducer. Compared to that just reserving > a tag and officially supporting the feature is much easier and a much > better story. This command is already special since we filter for it on the completion side. We may want to selectively filter other Set Feature commands too. For example, we don't want user space turning on Host Dispersed Namespace Support, because this driver is not going to correctly react to that one either.