Re: [PATCH RFC 3/3] nvme: delay failover by command quiesce timeout

[Sagi Grimberg]

On 16/04/2025 16:53, Mohamed Khalfella wrote:
> On 2025-04-16 10:30:11 +0200, Daniel Wagner wrote:
> > On Tue, Apr 15, 2025 at 05:40:16PM -0700, Mohamed Khalfella wrote:
> > > On 2025-04-15 14:17:48 +0200, Daniel Wagner wrote:
> > > > Pasthrough commands should fail immediately. Userland is in charge here,
> > > > not the kernel. At least this what should happen here.
> > > I see your point. Unless I am missing something these requests should be
> > > held equally to bio requests from multipath layer. Let us say app
> > > submitted write a request that got canceled immediately, how does the app
> > > know when it is safe to retry the write request?
> > Good question, but nothing new as far I can tell. If the kernel doesn't
> > start to retry passthru IO commands, we have to figure out how to pass
> > additional information to the userland.
> nvme multipath does not retry passthru commands. That is said, there is
> nothing prevents userspace from retrying canceled command immediately
> resulting in the unwanted behavior these very patches try to address.

userspace can read the controller cqt and implement the retry logic on 
its own.
If it doesn't/can't, it should use normal fs io. the driver does not 
handle passthru retries.

> > > Holding requests like write until it is safe to be retried is the whole
> > > point of this work, right?
> > My first goal was to address the IO commands submitted via the block
> > layer. I didn't had the IO passthru interface on my radar. I agree,
> > getting the IO passthru path correct is also good idea.
> Okay. This will be addressed in the next revision, right?

I don't think it should. passthru IO requires the issuer to understand 
the nvme
device, and CQT falls under this definition.