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

[Arlin Davis]

Caitlin Bestler wrote:

>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.
>  
>
I am not promoting these specific extensions for all providers, they are 
merely working examples that add value to the IB provider and are 
inlcuded so everyone can see exactly how the "proposed extension 
interface"can plug into new provider specific entry points (i.e. real 
code, working patch). Please concentrate on the extension method 
proposed and not the provider specific calls. I am looking for comments 
on the new extension function definition, extension event processing, 
event type and data extensions, and cookie extensions.

>An extension creates no similar expectations on other Providers.
>  
>
I agree.

>_______________________________________________
>openib-general mailing list
>openib-general at openib.org
>http://openib.org/mailman/listinfo/openib-general
>
>To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
>  
>