From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from verein.lst.de (verein.lst.de [213.95.11.211])
	(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 B245C32AABA
	for <linux-kernel@vger.kernel.org>; Mon, 17 Aug 2026 07:57:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1786953469; cv=none; b=iZ9sMypdG+zPiXU+Q+ejuTSI11cdfOa3l5rz/yFecdXaWlqq4nE3zhlOeb057wSgkuFaQoGYq7QMYASn/x37fG9oPD1qZoFoLKP6pcD214j9tCU29taIGsipgqwKwl+Vx0yNA61pC8hdnoiWWGZVjlRdELgtcj0f+pe9rUN40zI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1786953469; c=relaxed/simple;
	bh=A3nnhwN6C2BY2ZtXgzBaIq4RmyD+94mSoCv1jECW9YM=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Vhf/WpEukxVZH8TIZJh/S8gd/xZ6lsxxA8Kfvcrkxa+kLGGcSSgtoL4B9jhuU2wgzBWdgCSKSzc8QQSdp9l3dK60EKBIP2m1SBJNiY3kU9GxxORSGMz0UJ0aceECCiyndonWECR+zVM1G5npPog948+5DFKvZgu8tgZKvuAJD0U=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de
Received: by verein.lst.de (Postfix, from userid 2407)
	id 2F2D568CFE; Mon, 17 Aug 2026 09:57:44 +0200 (CEST)
Date: Mon, 17 Aug 2026 09:57:44 +0200
From: Christoph Hellwig <hch@lst.de>
To: Saravanan D <saravanand@crusoe.ai>
Cc: linux-nvme@lists.infradead.org, Keith Busch <kbusch@kernel.org>,
	Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
	Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme-tcp: pin io_cpu to submitter cpu
Message-ID: <20260817075743.GA20887@lst.de>
References: <20260806023947.94680-2-saravanand@crusoe.ai>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260806023947.94680-2-saravanand@crusoe.ai>
User-Agent: Mutt/1.5.17 (2007-11-01)

On Wed, Aug 05, 2026 at 07:39:44PM -0700, Saravanan D wrote:
> Adopt the submitting CPU of non passthrough requests as io_cpu. The
> submitter is a member of the map group by construction, and the
> nvme_tcp_cpu_queues accounting moves with each adoption. Passthrough
> commands do not participate since the io queue Connect arrives from an
> arbitrary group CPU via blk_mq_alloc_request_hctx(), so the first real
> read or write decides.

connect isn't the only passthrough command.  All your above reasoning
would apply to at least user passthrough commands as well.  Maybe
special casing connect is the better idea here?

> 
> Queues outlive the workloads that submit through them, so adoption
> re-arms after 30 seconds of queue quiet. An idle queue is reclaimed by
> its next submitter, while a busy queue keeps a stable io_cpu and
> cannot ping pong between two live submitters. Concurrent writers
> on different CPUs serialize on a cmpxchg on io_cpu.
> 
> The behavior is opt in via the new wq_adopt module parameter, default
> off and runtime writable. wq_unbound takes precedence when both are
> set.

I think you want this as an option at queue connect time.  Any specific
reason you picked the global module parameter?