All of lore.kernel.org
 help / color / mirror / Atom feed
From: swise@opengridcomputing.com (Steve Wise)
Subject: [PATCH 0/3] Fix request completion holes
Date: Thu, 2 Nov 2017 11:18:42 -0500	[thread overview]
Message-ID: <022e01d353f6$3fcbafd0$bf630f70$@opengridcomputing.com> (raw)
In-Reply-To: <20171102151254.GE18874@ziepe.ca>



> -----Original Message-----
> From: linux-rdma-owner at vger.kernel.org [mailto:linux-rdma-
> owner at vger.kernel.org] On Behalf Of Jason Gunthorpe
> Sent: Thursday, November 02, 2017 10:13 AM
> To: Sagi Grimberg
> Cc: idanb; Max Gurtovoy; linux-rdma at vger.kernel.org; linux-
> nvme at lists.infradead.org; Christoph Hellwig
> Subject: Re: [PATCH 0/3] Fix request completion holes
> 
> On Thu, Nov 02, 2017@10:06:30AM +0200, Sagi Grimberg wrote:
> >
> > >>the default mode utilize remote invalidation, so no, its not valid.
> > >
> > >Well, usually the ULP design should allow some things to be reaped
> > >async, and latency senstive things to be sync.
> > >
> > >Eg if you have a SEND using a local buffer with a RKEY, then you'd
> > >declare the RKEY data completed when SEND_WITH_INVALIDATE is returned.
> > >
> > >Recycling the lkey command buffer is an async process and can wait
> > >unsignaled until something signalled comes to push its completion
> > >through.
> >
> > Not when using inline data with the send, which is the main issue
> > here. if we inline data to the command, we will use the local
> > dma lkey, which does not even have a local invalidate following it.
> 
> Does nvme use inline data send and RKEY transfer in the same SEND?
> Then it would need to signal the SEND if remote invalidate is used,
> otherwise it only needs to signal the local invalidate for the RKEY..
> 
> > >Local invalidate is defined to always be ordered by the spec, so it
> > >is required to guarentee that the SEND is completed.
> 
> > So local invalidate completion is guaranteed to come after all the
> > completions prior to it in the send queue?
> 
> IBA spec says so..
> 

iWARP spec too.   This is in regard to completion ordering though.  The local
invalidate send WR must have the IB_SEND_FENCE flag set if you want it to only
be executed after all prior send WRs are executed.    Either way, the
completions are always inserted into the cq in-sq-submission-order and a
signaled completion implies completions of all prior unsignaled WRs.

Steve.

WARNING: multiple messages have this Message-ID (diff)
From: "Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
To: 'Jason Gunthorpe' <jgg-uk2M96/98Pc@public.gmane.org>,
	'Sagi Grimberg' <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
Cc: 'idanb' <idanb-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	'Max Gurtovoy' <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	'Christoph Hellwig' <hch-jcswGhMUV9g@public.gmane.org>
Subject: RE: [PATCH 0/3] Fix request completion holes
Date: Thu, 2 Nov 2017 11:18:42 -0500	[thread overview]
Message-ID: <022e01d353f6$3fcbafd0$bf630f70$@opengridcomputing.com> (raw)
In-Reply-To: <20171102151254.GE18874-uk2M96/98Pc@public.gmane.org>



> -----Original Message-----
> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Jason Gunthorpe
> Sent: Thursday, November 02, 2017 10:13 AM
> To: Sagi Grimberg
> Cc: idanb; Max Gurtovoy; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Christoph Hellwig
> Subject: Re: [PATCH 0/3] Fix request completion holes
> 
> On Thu, Nov 02, 2017 at 10:06:30AM +0200, Sagi Grimberg wrote:
> >
> > >>the default mode utilize remote invalidation, so no, its not valid.
> > >
> > >Well, usually the ULP design should allow some things to be reaped
> > >async, and latency senstive things to be sync.
> > >
> > >Eg if you have a SEND using a local buffer with a RKEY, then you'd
> > >declare the RKEY data completed when SEND_WITH_INVALIDATE is returned.
> > >
> > >Recycling the lkey command buffer is an async process and can wait
> > >unsignaled until something signalled comes to push its completion
> > >through.
> >
> > Not when using inline data with the send, which is the main issue
> > here. if we inline data to the command, we will use the local
> > dma lkey, which does not even have a local invalidate following it.
> 
> Does nvme use inline data send and RKEY transfer in the same SEND?
> Then it would need to signal the SEND if remote invalidate is used,
> otherwise it only needs to signal the local invalidate for the RKEY..
> 
> > >Local invalidate is defined to always be ordered by the spec, so it
> > >is required to guarentee that the SEND is completed.
> 
> > So local invalidate completion is guaranteed to come after all the
> > completions prior to it in the send queue?
> 
> IBA spec says so..
> 

iWARP spec too.   This is in regard to completion ordering though.  The local
invalidate send WR must have the IB_SEND_FENCE flag set if you want it to only
be executed after all prior send WRs are executed.    Either way, the
completions are always inserted into the cq in-sq-submission-order and a
signaled completion implies completions of all prior unsignaled WRs.

Steve.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2017-11-02 16:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31  8:55 [PATCH 0/3] Fix request completion holes Sagi Grimberg
2017-10-31  8:55 ` Sagi Grimberg
2017-10-31  8:55 ` [PATCH 1/3] nvme-rdma: don't suppress send completions Sagi Grimberg
2017-10-31  8:55   ` 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   ` 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  8:55   ` Sagi Grimberg
2017-10-31  9:38 ` [PATCH 0/3] Fix request completion holes Max Gurtovoy
2017-10-31  9:38   ` Max Gurtovoy
2017-10-31 11:10   ` Sagi Grimberg
2017-10-31 11:10     ` Sagi Grimberg
2017-11-01 16:02     ` idanb
2017-11-01 16:02       ` idanb
2017-11-01 16:09       ` Max Gurtovoy
2017-11-01 16:09         ` Max Gurtovoy
2017-11-01 16:50       ` Jason Gunthorpe
2017-11-01 16:50         ` Jason Gunthorpe
2017-11-01 17:31         ` Sagi Grimberg
2017-11-01 17:31           ` Sagi Grimberg
2017-11-01 17:58           ` Jason Gunthorpe
2017-11-01 17:58             ` Jason Gunthorpe
2017-11-02  8:06             ` Sagi Grimberg
2017-11-02  8:06               ` Sagi Grimberg
2017-11-02 15:12               ` Jason Gunthorpe
2017-11-02 15:12                 ` Jason Gunthorpe
2017-11-02 15:23                 ` Sagi Grimberg
2017-11-02 15:23                   ` Sagi Grimberg
2017-11-02 15:51                   ` Jason Gunthorpe
2017-11-02 15:51                     ` Jason Gunthorpe
2017-11-02 16:15                     ` Sagi Grimberg
2017-11-02 16:15                       ` Sagi Grimberg
2017-11-02 16:18                 ` Steve Wise [this message]
2017-11-02 16:18                   ` Steve Wise
2017-11-02 16:36                   ` Jason Gunthorpe
2017-11-02 16:36                     ` Jason Gunthorpe
2017-11-02 16:53                     ` Steve Wise
2017-11-02 16:53                       ` Steve Wise
2017-11-02 16:54                       ` Jason Gunthorpe
2017-11-02 16:54                         ` Jason Gunthorpe
2017-11-01 17:26       ` Sagi Grimberg
2017-11-01 17:26         ` Sagi Grimberg
2017-11-01 22:23         ` Max Gurtovoy
2017-11-01 22:23           ` Max Gurtovoy
2017-11-02 17:55         ` Steve Wise
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='022e01d353f6$3fcbafd0$bf630f70$@opengridcomputing.com' \
    --to=swise@opengridcomputing.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.