[openib-general] RE: [RFC] DAT 2.0 immediate data proposal
Kanevsky, Arkady
Arkady.Kanevsky at netapp.com
Tue Jan 17 07:16:27 PST 2006
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: arkady at netapp.com
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:arlin.r.davis at intel.com]
Sent: Monday, January 16, 2006 5:55 PM
To: Kanevsky, Arkady; Lentini, James
Cc: dat-discussions at yahoogroups.com; openib-general at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060117/fc775229/attachment.html>
More information about the general
mailing list