[openib-general] [PATCH 0/6] Tranport Neutral Verbs Proposal.

[Caitlin Bestler]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of Greg Lindahl
> Sent: Monday, July 31, 2006 10:38 AM
> To: James Lentini
> Cc: openib-general
> Subject: Re: [openib-general] [PATCH 0/6] Tranport Neutral 
> Verbs Proposal.
> 
> On Mon, Jul 31, 2006 at 01:25:39PM -0400, James Lentini wrote:
> 
> > I agree that the term RDMA SEND is confusing. However, the 
> data in an 
> > RDMA SEND is deposited directly (zero copy) into the users memory.
> 
> There are many mechanisms other than DMA or RDMA which have 
> this property. You're confusing specification with 
> implementation, too.
> When I read from a disk on modern Unix, the data is deposited 
> into the user's memory, whether it's DMA or PIO.
> 
> The defining characteristic of RDMA is that it deposits or 
> reads data based on address provided by the other side, *and* 
> that it has one-sided semantics. In ordinary messaging, data 
> is transferred from buffers which are much less flexibly 
> addressed, and semantics are two-sided.
> 

Trying to characterize "RDMA" as consisting *solely* of 
messages that identify target buffers in the message is
off target.

RDMA protocols rely on the combination of messages that
name their target buffer and messages that target "anonymous"
buffers (that are selected by the Data Sink). The iWARP
terminology, "tagged" and "untagged" is actually quite
useful here and it helps emphasize that the two techniques
complement each other.

The more informative distinction between "RDMA" and conventional
networking is that with RDMA even the "anonymous" buffers come
directly from the user (not from system buffering), MUST be
pre-posted (via RQ or SRQ) and MUST be enabled (registered)
for RDMA access explicitly by a layer *above* RDMA.

Now if you can come up with a short acronym that conveys
that then I am fine with using it. But avoid explanations
that imply that RDMA SEND/RECV is somehow less part of "RDMA"
than "RDMA Write" or "RDMA Read". Trying to use "openfabrics"
either results in something too long or insufficiently clear
when viewed in the context of the kernel as a whole ("of_"?).