[openib-general] RE: [RFC] DAT 2.0 extension proposal

Arlin Davis ardavis at ichips.intel.com
Tue Jan 17 11:28:03 PST 2006


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



More information about the general mailing list