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

[Larsen, Roy K]

Caitlin Bestler wrote:
>
>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).

No, iWARP *CAN NOT* implement write immediate data any better than IB
can implement send with invalidate.  Immediate data *MUST* be indicated
to the ULP unambiguously.  Imposing an algorithm on the application to
infer immediate data arrival is hack, pure and simple. An application is
free to perform a write/send if that is the semantic they want.  Why
does iWARP get transport unique APIs but not IB?  I find this attempt to
bastardize the IB semantic of immediate data a little curious.

Roy