Kanevsky, Arkady wrote:
Arlin,
1. Does it mean that existing DAT providers will have to be modified
so they report
DAT_NOT_IMPLEMENTED for each extension?
No.
During the open, a dat library built to support extensions, a query call
is made to verify that the provider supports extensions and sets a
global flag accordingly. This flag is checked via our single
dat_extension call in dat_api. Take a look at the patch for all the details.
2. Why is there DAT_INVALID in DAT_DTOS?
no reason. I can get rid of it. I will go ahead and keep this in sync
with the latest 1.3 (2.0) definitions.
3. Do you want to use DAT_EXTENSION_DATA or DAT_EXT_DATA?
sure.
4. The proposed operations are operation on EP and they are DTOs.
Why not define DAT_DTO_EXT_OP instead of DAT_EXT_OP?
Yes, it makes more sense if we decide to limit these extensions to DTO
types.
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.
I have no problem limiting this proposal and work to DTO extensions.
However, we should get consensus on this.
5. Memory protection extension for atomic operations
6. error returns for extensions?
yes and yes; I will work these into the next patch and update the proposal.
-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
