[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZHeceyZ9eUC27WcE@ziepe.ca>
Date: Wed, 31 May 2023 16:14:03 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Huacai Chen <chenhuacai@...il.com>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Bjorn Helgaas <helgaas@...nel.org>,
Huacai Chen <chenhuacai@...ngson.cn>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
"Ahmed S . Darwish" <darwi@...utronix.de>,
Kevin Tian <kevin.tian@...el.com>, linux-pci@...r.kernel.org,
Jianmin Lv <lvjianmin@...ngson.cn>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
loongson-kernel@...ts.loongnix.cn,
Juxin Gao <gaojuxin@...ngson.cn>,
Marc Zyngier <maz@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pci: irq: Add an early parameter to limit pci irq numbers
On Mon, May 29, 2023 at 02:52:29PM +0800, Huacai Chen wrote:
> > But IMO what you are proposing seems like usecase driven and may not work all
> > the time due to architecture limitation. This again proves that the existing
> > solution is sufficient enough.
> Yes, it's a usecase driven solution, so I provide a cmdline parameter
> to let the user decide.
The NIC drivers should be consuming interrupts based on the number of
queues they are using, and that is something you can control from the
command line, eg ethtool IIRC. Usually it defaults to the number of
CPUs.
Basically, you want to enable the user to configure the system with a
user specified reduced number of NIC queues, and we already have way
to do that.
Jason
Powered by blists - more mailing lists