[dat-discussions] [openib-general] [RFC] DAT2.0immediatedataproposal

[Caitlin Bestler]

Arlin Davis wrote:
> Sean Hefty wrote:
> 
>>> The requirement is to provide an API that supports RDMA writes with
>>> immediate data.  A send that follows an RDMA write is not immediate
>>> data, and the API should not be constructed around trying to make
>>> it so. 
>>> 
>>> 
>> 
>> To be clear, I believe that write with immediate should be part of
>> the normal APIs, rather than an extension, but should be designed
>> around those devices that provide it natively.
>> 
>> 
> I totally agree. A standard RDMA write with immediate API can
> be very useful to RDMA applications based on the requirements
> (native support) set forth in my earlier email. It is analogous to
> the new dat_ep_post_send_with_invalidate() call; a call that supports
> a native iWARP transport operation but provides no provisions
> to help other transports emulate. So, other transports simply
> return NOT_SUPPORTED and add it natively in the future if it makes
> sense. 
> 
> -arlin

What is proposed in a definition of
'dat_ep_post_rdma_write_with_immediate'
that can be implemented over iWARP using the sequence of messages that
were intended to support the same purpose (i.e., letting the other
side know that an RDMA Write transfer has been fully received).

This definition also conforms to all existing DAT ordering rules.

Is there anything wrong with this definition for an IB provider?

There is a similarity between write_with_immediate and
send_with_invalidate
in that they combine operations which a) are already logically tied 
from the consumer's perspective and b) can be more easily optimized
by the Provider over the wire when presented as one request.

Indeed, with send_with_invalidate it *has* to be optimized since
you cannot send the invalidate later.