[openib-general] Re: [RFC][PATCH] OpenIB uDAPL extension proposal - sample immed data and atomic api's

[Caitlin Bestler]

openib-general-bounces at openib.org wrote:
> arlin> DAPL provides a generalized abstraction to RDMA capable
> arlin> transports. As a generalized abstraction, it cannot
> exploit the
> arlin> unique properties that many of the underlying
> arlin> platforms/interconnects can provide so I would like to propose
> a arlin> simple (minimum impact on libdat) extensible interface
> to uDAPL
> arlin> that will allow vendors to expose such capabilities. I
> am looking
> arlin> for feedback, especially from the DAT collaborative. I have
> arlin> included both a design document and actual working code as a
> arlin> reference. 
> 
> This is an excellent document and clearly certain
> applications will benefit greatly from adding this additional
> functionality. 
> 
> Since DAPL's inception, the DAT_PROVIDER structure has
> contained a field called "extension" of type void *. The
> purpose of this field was to allow for the kind of
> provider/platform/interconnect specific extensions you describe.
> 
> I believe these features can be added without modifications
> to the current API by defining a particular format for the
> DAT_PROVIDER's extension data and indicating its presence via
> a provider attribute.
> That would require creating an extension document like this
> one describing an "extension" structure w/ function pointers
> to the new functions and a well known provider attribute value.
> 
> Is there a reason this was not feasible? Would minor
> modifications to the existing framework be sufficient
> (perhaps an "extension" event type)?
> 


Good points.

Promoting something from a provider-specific extension, or even
an extension that many providers agree to, creates an expectation
that other providers SHOULD implement at least an emulation of
this new method if it is at all relevant on their transport.
And at the minimum they have to explicitly reject calls to
the new method.

An extension creates no similar expectations on other Providers.