[PATCH V3 3/3] nvme: retry commands based on ACRE flag

[Minwoo Im]

On 21-01-20 03:28:38, Keith Busch wrote:
> On Mon, Jan 18, 2021 at 06:40:51PM +0100, Christoph Hellwig wrote:
> > On Sat, Jan 16, 2021 at 03:26:02AM +0900, Minwoo Im wrote:
> > > > I am not sure we should ignore the FAILFAST for non-path errors. If we
> > > > need retryable admin commands, we should let the driver provide a way
> > > > for callers to dispatch requests without that flag.
> > > 
> > > Understood.  I thought the opposite way about FAILFAST in case with
> > > acre, if device is enabled with acre, all commands would be retried
> > > regardless to FAILFAST...  Thanks for pointing that out!
> > > 
> > > How do you think which one is right choice to go with if a user-space
> > > application(e.g., nvme-cli) wants a command to be retired in case of
> > > ACRE && Error && !DNR:
> > > 
> > >   - User-space application should figure out !DNR and retry the command.
> > >     (Maybe we are not able to easily figure out exact status code from
> > >     the user-space application by the return value).
> > > 
> > >   - Driver should retry the command right before putting result up to
> > >     the user-space even it's a FAILFAST request.
> > > 
> > > Thanks,
> > 
> > We could come up with a version of the ioctls that use the normal
> > retry mechanisms.  nvme_passthru_cmd64 has two reserved fields we
> > could use for UAPI flags like this.
> 
> Yeah, I'm totally okay with adding driver control flags for this sort of
> behavior.
> 
> For the moment, the ioctl interface has always been 1:1 for commands
> submitted to completions received, so all user space applications using
> this should have been prepared to receive unfiltered status back and
> handle retries on their own.

Thanks Keith for your feedback!