Davis, Arlin R wrote:
*Maybe we need to just go back to one model and always deliver via the
event? With the post_recv_immed requirements, other transports have a
mechanism to emulate and create the necessary resources on the recv side
to place idata and copy to event when operation is completed. Would this
work for iWARP?*
You don't want post_recv_immed. The receiver shouldn't have to indicate whether
a receive will get immediate data or not.
12. Is your intension that post_recv_immed can ONLY except immediate
data and is not capable to recv any message?
*No, the intention is to extend the post_recv to handle 32bit idata
which may arrive with or without other send or rdma_write data.*
*Does it make more sense to add a dto_flags to the existing post_recv?*
This looks like an API designed around hardware that doesn't support immediate
data, rather than one that actually does. Post_recv_immed doesn't map to IB.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
