[dat-discussions] [openib-general] [RFC] DAT 2.0immediatedataproposal

[Caitlin Bestler]

Sean Hefty wrote:
>> 	And further it is only on the receiving side.
>> 	And only if the receiving side cares about the data
>> 		(sometimes it only needs the notification).
> 
> The send size cares about this check because it must size its SQ
> appropriately. I disagree with the assumption that a "transport
> neutral" API is inherently easier for the application developer.
> 
>> The attempt is to define a composite work request that can reduce the
>> number of actual work requests required for some providers, without
>> requiring different work flows dependent on whether the "immediate"
>> feature was present.
> 
> This is exactly what Roy was pointing out.  This is no longer
> defining a write with immediate data, but instead addressing
> some other requirement.  In this case, you can define a
> generic send side API that takes multiple work requests as
> input, since a provider may be able to reduce the actual
> number of work requests in this case as well.
> 
> - Sean

Yes such an interface is more general. It would be something
along the lines of dat_ep_post_exchnage() which would post
the SGLs for zero or more RDMA Writes and a single RDMA Send.
It would be matched on the other end by a single receive.

Would that be easy for IB vendors to optimize? It's pretty
much the same for an iWARP provider.