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

[Larsen, Roy K]

>>> Completing a transaction, complete with supplying a transaction
>>> response and releasing the advertised STag associated with the
>>> transaction is something that makes sense in the application domain
>>> and conforms to normal DAT ordering rules.
>>>
>>
>> I don't disagree.  And unambiguous immediate data indications
>> fall into that same category which is why I'm puzzled there is so
>> much resistance.
>>
>>> "Provide information about an RDMA Write to a receive operation"
>>> also meets that definition -- as long as it conforms to the existing
>>> ordering rules. Shifting to an 8 byte message over iWARP to allow
for
>>> the write length *and* immediate 'tag'
>>> is certainly doable. We could even consider having the DAT Provider
>>> supply the 'buffer' silently in the DTO itself.
>>>
>>
>> If you make the receive indication unambiguous as to the fact
>> it's associated with a write immediate, you've got my full
>> support, even if immediate data is delivered differently by
>> different transports.  If not, it is nothing more than a
>> write/send that the application can do itself.
>>
>
>From the viewpoint of the Provider/RNIC/driver there is no
>wire Send message which can be known to be associated with
>an RDMA Write. Up to the maximum message size, any combination
>of bytes are legal.
>
>Therefore this is a distinct that an iWARP provider CANNOT make.
>Unlike send with invalidate, which CAN be supported under IB 1.2.

So, your stance is that if an RDMA transport protocol specification
exists that can't support or emulate a service faithfully, an API can't
exist for that service in DAPL.  Ok, that makes this discussion much
clearer and to the point.

>Keep in mind that under the basic DAT semantics, RDMA Writes
>are *not* signalled to the Data Sink. That was settled years ago.
>
>So under DAT semantics you use a Send to cause a completion at
>the other end -- period.

Addressed below...

>
>What we are talking about is whether to allow short sends that
>supply a minimal set of standard information to be piggy-backed
>on a prior RDMA Write by making it an RDMA Write with immediate.

That is not what those advocating immediate data have been talking
about.  It has always been whether the IB capability could be exposed to
the ULP.  Remember, the first proposal by Arlin was to make this an
extension.  This list wanted to expose it as a formal API.  So, I find
that assertion puzzling.

>I am not opposed to allowing IB Providers to do that. I am opposed
>to changing the fundamental DAT semantics that RDMA Writes are not
>visible the Data Sink. Conceptually, a Send is required.
>

Conceptual, eh?  Well, of course IB immediate data *is* indicated on the
receive queue.  Not conceptual enough?  But that aside, it is a rather
strict and convenient interpretation.  Are you sure you want to put a
stake that deep in the ground about all currently defined DAPL semantics
against transport standards that evolve, or just those that can't be
implemented by all transports?

I was under the assumption that the DAT community defined the APIs and
semantics through an open process.  Given that the IB write immediate
data facility does not break the implementation or semantics of the
currently defined RDMA write facility, I see no reason the DAPL spec
couldn't be updated, through consensus, with the realities of existing
transport services.  Nevertheless, I presume you'll have no objection to
implementing this useful service as a DAPL extension since the semantic
rules for extensions haven't been define yet.

Roy