public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brean <David.Brean-UdXhSnd/wVw@public.gmane.org>
To: Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Richard Frank
	<richard.frank-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
	linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: strong ordering for data registered memory
Date: Thu, 12 Nov 2009 15:43:02 -0500	[thread overview]
Message-ID: <4AFC7356.8060602@Sun.COM> (raw)
In-Reply-To: <20091111231338.GZ1966-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

See section 4 in the paper called "High Performance RDMA Based MPI Implementation over InfiniBand" on the MVAPICH web page for description of one implementation that polls on data buffers.  Specifically, look at text around the statement "Although the approach uses the in-order implementation of hardware for RDMA write which is not specified in the InfiniBand standard, this feature is very likely to be kept by different hardware designers."  Although this paper is describing a PCI-X implementation, the feature is also exists on PCIe.

It's assumed that the host memory interconnect complies with statements described in the "Update Ordering and Granularity Provided by a Write Transaction" of the PCI spec.  This particular application depends on PCI WRITE behavior, not READ.

Does this help?

Jason Gunthorpe wrote:
> On Wed, Nov 11, 2009 at 05:44:59PM -0500, Richard Frank wrote:
> 
>> Would anyone like to through out the list of HCAs that do this... I
>> can guess at a few...  and can ask the vendors directly.. if not.. .
>>
>> It would be much nicer to not hardcode names of adapters.. but that won't
>> stop us.. :)
> 
> Isn't it more complex than this? AFAIK the PCI-E standard does not
> specify the order which data inside a single transfer becomes visible,
> only how different transfers relate. To work on the most agressive
> PCI-E system the HCA would have to transfer the last XX bytes as a
> seperate PCI-E transaction without relaxed ordering.
> 
> This is the sort of thing that might start to matter on QPI and HT
> memory-interleaved configurations. A multi-cache line transfer will be
> split up and completed on different chips - it may not be fully
> coherent 100% of the time.
> 
> Jason
--
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:[~2009-11-12 20:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10 20:19 strong ordering for data registered memory David Brean
     [not found] ` <4AF9CACE.8070700-UdXhSnd/wVw@public.gmane.org>
2009-11-11 17:57   ` Roland Dreier
     [not found]     ` <adaskclvta4.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2009-11-11 18:16       ` Richard Frank
     [not found]         ` <4AFAFF7A.4090602-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2009-11-11 22:11           ` David Brean
     [not found]             ` <4AFB3677.6050603-UdXhSnd/wVw@public.gmane.org>
2009-11-11 22:44               ` Richard Frank
     [not found]                 ` <4AFB3E6B.3080606-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2009-11-11 23:13                   ` Jason Gunthorpe
     [not found]                     ` <20091111231338.GZ1966-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2009-11-12  5:41                       ` Dave Olson
2009-11-12 20:43                       ` David Brean [this message]
2009-11-11 21:37       ` David Brean
     [not found]         ` <4AFB2EA5.4030804-UdXhSnd/wVw@public.gmane.org>
2009-11-11 23:06           ` Roland Dreier
     [not found]             ` <ada639gvezo.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2009-11-12 20:42               ` David Brean
  -- strict thread matches above, loose matches on Subject: below --
2009-11-12 21:51 Caitlin Bestler

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=4AFC7356.8060602@Sun.COM \
    --to=david.brean-udxhsnd/wvw@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
    --cc=richard.frank-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    /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