[PATCHv2] nvme-pci: allow unmanaged interrupts

[Keith Busch]

On Mon, May 13, 2024 at 09:12:58AM +0800, Ming Lei wrote:
> On Sun, May 12, 2024 at 05:16:13PM +0300, Sagi Grimberg wrote:
> > 
> > > > Everyone expects nvme performance will suffer. IO latency and CPU
> > > > efficieny are not everyone's top priority, so allowing people to
> > > > optimize for something else seems like a reasonable request.
> > > I guess more people may be interested in 'something else', care to share
> > > them in the commit log, cause nvme is going to support it.
> > 
> > I don't have a special interest in this, but I can share what I heard
> > several
> > times. The use-case is that people want to dedicate a few cores to handle
> > interrupts so they know it does not take cpu time from their application
> > threads
> > that are running (usually pinned to different cores).
> > 
> > The app threads isolation is more important to them than affinity to the
> > device...
> 
> That is exactly what CPU isolation is doing, include 'isolcpus=managed_irq',
> isn't it?

As I've mentioned previously, that option is a no-op when the incoming
mask matches the isolcated cpus. The use case for the kernel's isolated
CPUs doesn't align with the use cases for user defined IRQ affinity.

Let me redirect this discussion please. Is there a techincal reason why
Linux can't let users use their CPUs as they intend? They will take out
of tree patches if that's the position we're forceing them into, but why
is that is Linux taking that position in the first place?