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:

quoted

quoted

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.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme