linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sagi@grimberg.me (Sagi Grimberg)
Subject: [PATCH 0/3] Fix request completion holes
Date: Tue, 31 Oct 2017 10:55:19 +0200	[thread overview]
Message-ID: <1509440122-1190-1-git-send-email-sagi@grimberg.me> (raw)

We have two holes in nvme-rdma when completing request.

1. We never wait for send work request to complete before completing
a request. It is possible that the HCA retries a send operation (due
to dropped ack) after the nvme cqe has already arrived back to the host.
If we unmap the host buffer upon reception of the cqe, the HCA might
get iommu errors when attempting to access an unmapped host buffer.
We must wait also for the send completion before completing a request,
most of the time it will be before the nvme cqe has arrived back so
we pay only for the extra cq entry processing.

2. We don't wait for the request memory region to be fully invalidated
in case the target didn't invalidate remotely. We must wait for the local
invalidation to complete before completing the request.

Sagi Grimberg (3):
  nvme-rdma: don't suppress send completions
  nvme-rdma: don't complete requests before a send work request has
    completed
  nvme-rdma: wait for local invalidation before completing a request

 drivers/nvme/host/rdma.c | 101 +++++++++++++++++++++++------------------------
 1 file changed, 50 insertions(+), 51 deletions(-)

-- 
2.7.4

             reply	other threads:[~2017-10-31  8:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31  8:55 Sagi Grimberg [this message]
2017-10-31  8:55 ` [PATCH 1/3] nvme-rdma: don't suppress send completions Sagi Grimberg
2017-10-31  8:55 ` [PATCH 2/3] nvme-rdma: don't complete requests before a send work request has completed Sagi Grimberg
2017-10-31  8:55 ` [PATCH 3/3] nvme-rdma: wait for local invalidation before completing a request Sagi Grimberg
2017-10-31  9:38 ` [PATCH 0/3] Fix request completion holes Max Gurtovoy
2017-10-31 11:10   ` Sagi Grimberg
2017-11-01 16:02     ` idanb
2017-11-01 16:09       ` Max Gurtovoy
2017-11-01 16:50       ` Jason Gunthorpe
2017-11-01 17:31         ` Sagi Grimberg
2017-11-01 17:58           ` Jason Gunthorpe
2017-11-02  8:06             ` Sagi Grimberg
2017-11-02 15:12               ` Jason Gunthorpe
2017-11-02 15:23                 ` Sagi Grimberg
2017-11-02 15:51                   ` Jason Gunthorpe
2017-11-02 16:15                     ` Sagi Grimberg
2017-11-02 16:18                 ` Steve Wise
2017-11-02 16:36                   ` Jason Gunthorpe
2017-11-02 16:53                     ` Steve Wise
2017-11-02 16:54                       ` Jason Gunthorpe
2017-11-01 17:26       ` Sagi Grimberg
2017-11-01 22:23         ` Max Gurtovoy
2017-11-02 17:55         ` Steve Wise

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1509440122-1190-1-git-send-email-sagi@grimberg.me \
    --to=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).