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

Caitlin Bestler caitlinb at broadcom.com
Tue Feb 7 14:27:15 PST 2006


Larsen, Roy K wrote:

> 
>> 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.

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.

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.

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.

And as with all Send Messages, it is up to the *application* to
ensure tha their meaning is known at the Data Sink. This can be
done by ordering and/or content of the data.





More information about the general mailing list