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 111FE46D2C2
	for <linux-kernel@vger.kernel.org>; Tue,  4 Aug 2026 14:10:28 +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=1785852631; cv=none; b=avUqKCHaAoQ9pyc8QJNQtw7JxFXrzmTlcCQobnCXPsE4LJqsqxof3bQ7B+ROmkMFvqt/4HYNgiKewNS0lKkcQmrVOea4PC4T158yp+NIFq/d5YNlVV34UI+jCWKvmVO1AT48vsRzwE3u8tBXagdkSVF+10DCoa4UGRViJYKhPHE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1785852631; c=relaxed/simple;
	bh=7uR5MufAQNdkuJ0PiruCtjUnGz5K1w/31DMGSKkS6b0=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Hv3J/VIvsN8SSy9x3pPmhdbxNUKRZp1FhEUjReaGowoJ66gUguWOJsfIHqVI8xUrvXhu79oQw/feHcPpeUR1inmsfsV68wV72F2TvBatmAABwR4anaqgbNyaB3BUytR/0aYbZNV/a5hJ1IDblPBPdJ7ZLcWxZ6JW4GpsyBejSZM=
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 5B39B68C7B; Tue,  4 Aug 2026 16:10:24 +0200 (CEST)
Date: Tue, 4 Aug 2026 16:10:23 +0200
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	santhosh kumar <santhu.linux@gmail.com>,
	linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Ming Lei <ming.lei@redhat.com>, x86@kernel.org
Subject: Re: [RFC] PCI_IRQ_AFFINITY limits MSI-X allocation on 384 CPU /
 1000+ NVMe system
Message-ID: <20260804141023.GA9171@lst.de>
References: <CAKudn=rGv-xwAwTis8wpg31mxekyE4YH-E8CQoDTYovsPrENnQ@mail.gmail.com> <87cxw6hgli.ffs@fw13> <CAKudn=o7C1xa8TN6pqJeJQ1Wy=6iknHsyttW_Yo07n3_Yq5GCg@mail.gmail.com> <87ldasfwht.ffs@fw13> <amtRhu7KdGyHIwVf@kbusch-mbp> <87ik5wfeju.ffs@fw13> <anC3P7QCS46WGDo5@kbusch-mbp>
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: <anC3P7QCS46WGDo5@kbusch-mbp>
User-Agent: Mutt/1.5.17 (2007-11-01)

On Mon, Aug 03, 2026 at 05:43:59AM -1000, Keith Busch wrote:
> On Thu, Jul 30, 2026 at 09:44:21PM +0200, Thomas Gleixner wrote:
> > On Thu, Jul 30 2026 at 07:28, Keith Busch wrote:
> > > We can introduce a module parameter to throttle down the maximum number
> > > of IO queues to allocate per controller. I don't think the driver can
> > > automatically reason out what the correct number should be because it
> > > doesn't know how many devices it's going to see.
> > 
> > I might be missing something here as usual, but the number of io queues
> > per controller does not affect that at all as I explained before.
> 
> Oh, you did explain that. I skipped to the end as I had too many
> distractions last week. Sorry about that, and thanks for the
> re-explanation.
> 
> I mistakenly was thinking the effective_affinity was the only hardware
> resource used. Back to the drawing board.

But given that we don't use multiple tag_set by default this can't
be the issue of the reported unless they didnt report enabling
multiple tag sets.