Arlin,
 
1. Does it mean that existing DAT providers will have to be modified so they report
DAT_NOT_IMPLEMENTED for each extension?
 
2. Why is there DAT_INVALID in DAT_DTOS?
 
3. Do you want to use DAT_EXTENSION_DATA or DAT_EXT_DATA?
 
4. The proposed operations are operation on EP and they are DTOs.
Why not define DAT_DTO_EXT_OP instead of DAT_EXT_OP?
 
MY concern is that if these are not DTO then we have a new event stream type
for "extensions" and we need to define rules for this event stream including
ordering rules and interactions with other event streams, provider attributes
for stream mixing and so on...
 
If we restrict extensions to DTO operation extension we avoid all these issues
and simplify APIs. On the negative side these extension are restrictive.
 
5. Memory protection extension for atomic operations
 
6. error returns for extensions?
 
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: Davis, Arlin R [mailto:[EMAIL PROTECTED]
Sent: Monday, January 16, 2006 5:55 PM
To: Kanevsky, Arkady; Lentini, James
Cc: [EMAIL PROTECTED]; [email protected]
Subject: [RFC] DAT 2.0 extension proposal

Arkady,

 

The attached proposal adds generic DTO extensions and provider specific atomic operations as follow.

 

dat_ep_post_cmp_and_swap()

dat_ep_post_fetch_and_add()

 

The patch should be ready by tomorrow.

 

Thanks,

 

-arlin

 

 

_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

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

Reply via email to