[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