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

[Larsen, Roy K]

>But why define an IB specific feature when a transport neutral feature
>can be defined?
>
>Viewing the operation as Write with following Send maintains transport
>neutral semantics AND allows IB to encode it as a Write with Immediate.
>
>That avoids IB to use the silicon that already exists to support
>compressing
>the Write and Send into a single message. That is the real benefit,
isn't
>it?

No, it's not....

>And for both transports it enables the Provider to pass the 4 byte
>immediate
>data by value rather than by registered reference. So there is a
definite
>benefit
>to IB, and a potential benefit to IP, and it works for both transports.
>
>The *only* thing gained by making it a transport specific method is
>the implicit 33rd bit in the "that RDMA Write payload you asked for
>has arrived" message.
>

Ok, finally.  A realization that the semantics of write/send are not the
same as IB write with immediate data.  And the difference is important.
The proposed emulation could not pass a black box test since nothing
distinguishes an "immediate" receive message from standard one
containing rkeys or any other random data an application my need to
exchange through send/receive.  A true write with immediate data can
pass such a black box test because it offers a unique service whereas
the proposed emulation does not.  It is a "helper" function that uses
existing services.  I have no objection to a write/send helper function,
just call it that and not write with immediate data.  Leave the true
immediate data service as an extension as first proposed.

>Is there a concrete example of any benefit from encoding a 33rd bit in
>the selection of Write with Immediate versus Write followed by 32-bit
Send?

Yes, as stated several times, applications that use the send/receive
facility to exchange information such as rkeys as well as using write
immediate services must be able to unambiguously tell the difference
between receive indications.  Putting a requirement on the application
to make that distinction by their own devices provides no additional
service that they don't already have in existing APIs.

Roy