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

[James Lentini]

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 
arlin> a simple (minimum impact on libdat) extensible interface to 
arlin> uDAPL that will allow vendors to expose such capabilities. I am 
arlin> looking for feedback, especially from the DAT collaborative. I 
arlin> have included both a design document and actual working code as 
arlin> a 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)?

james