[openib-general] RE: [RFC] DAT 2.0 immediate data proposal

[Kanevsky, Arkady]

Arlin, a few things need to be addressed.   1. correlation with local and remote invalidate This potentially effects both DAT_DTOs and post operations   2. Need a precise defintion for CONFIRM_FLAG definition in a transport independent fashion. What guarantees DAT Provider "provides" on successful local completion? Remote end guarantee?   My understanding what you are trying to do is create 2 models one IB and one for iWARP. So for IB Consumers will use CONFIRM_FLAG and for iWARP IMMED_FLAG. Provider will indicate in Provider_attr which model it supports.   The issue I have with it is that I do not see a model that Consumer can use to create a transport independent code. It looks like Immed_flag can be made transport independent. But with "sender" specifying the behavior a protocol extension is needed for IB. IB will always deliver Immediate data in the header not a payload and remote Provider can control how it is delivered to a Consumer. But this means that there is no need for DTO_flags for Send side. Instead it can be used for Recv side or controlled purely by Provider.   3. Need to define error behavior. for new operations, async errors, EP behavior.   4. Need to define DAT_Provider attributes for immediate data and dto_flags behavior   5. Does Solicited_wait completion_flag value now applicable for RDMA_write for immediate data?   6. Is dto_completion_data xfer_length include immediate_data size or not?   7. what memory privilages needed for a recv buffer for immediate data?   8. SRQ interaction?   9. What happens of buffer for recv operation NOT recv_immed is matched for incomming recv/rdma_write op?   10. Change dat_ep_post_write_immed to dat_ep_post_rdma_write_immed to be consistent with current terminology.   11. Need to cleanup operation description to make it clear that Send|RDMA_write and immediate data part is a single atomic operation. The current "followed by" language is misleading. Make it explicit that there is a single local DTO completion and single remote DTO completion.   12. Is your intension that post_recv_immed can ONLY except immediate data and is not capable to recv any message?   13. size should be num_segments for dat_ep_post_recv_immed()   Arkady   Arkady Kanevsky                       email: [EMAIL PROTECTED] Network Appliance Inc.               phone: 781-768-5395 1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195 Waltham, MA 02451                   central phone: 781-768-5300   From: Arlin Davis [mailto:[EMAIL PROTECTED] Sent: Monday, January 16, 2006 5:55 PM To: Kanevsky, Arkady; Lentini, James Cc: [EMAIL PROTECTED]; openib-general@openib.org Subject: [RFC] DAT 2.0 immediate data proposal Arkady,   The attached proposal adds immediate data options as standard API’s instead of extensions for the following calls.   dat_ep_post_send_immed() dat_ep_post_recv_immed() dat_ep_post_write_immed()   The patch should be ready by tomorrow.   Thanks,   -arlin

_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general