[PATCH] nvme-tcp: always fail a request when sending it failed

Daniel Wagner dwagner at suse.de
Sun Jun 26 23:48:28 PDT 2022


On Sun, Jun 26, 2022 at 12:24:51PM +0300, Sagi Grimberg wrote:
> queue stoppage and inflight requests cancellation is fully fenced from
> io_work and thus failing a request from this context. Hence we don't
> need to try to guess from the socket retcode if this failure is because
> the queue is about to be torn down or not.
> 
> We are perfectly safe to just fail it, the request will not be cancelled
> later on.
> 
> This solves possible very long shutdown delays when the users issues a
> 'nvme disconnect-all'
> 
> Reported-by: Daniel Wagner <dwagner at suse.de>
> Signed-off-by: Sagi Grimberg <sagi at grimberg.me>

I've tested the case where we disconnect all controllers in a multipath
setup. In this scenario we reliable ended up waiting for a register
read/write in the shutdown path. With this path, the I/O fails
immediately and we don't wait the extra time out time for the I/O to fail
eventually.

Tested-by: Daniel Wagner <dwagner at suse.de>

> ---
>  drivers/nvme/host/tcp.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> index bb67538d241b..009c2cf3f106 100644
> --- a/drivers/nvme/host/tcp.c
> +++ b/drivers/nvme/host/tcp.c
> @@ -1180,8 +1180,7 @@ static int nvme_tcp_try_send(struct nvme_tcp_queue *queue)
>  	} else if (ret < 0) {
>  		dev_err(queue->ctrl->ctrl.device,
>  			"failed to send request %d\n", ret);
> -		if (ret != -EPIPE && ret != -ECONNRESET)
> -			nvme_tcp_fail_request(queue->request);
> +		nvme_tcp_fail_request(queue->request);
>  		nvme_tcp_done_send_req(queue);
>  	}
>  	return ret;
> -- 
> 2.34.1
> 



More information about the Linux-nvme mailing list