Caitlin Bestler wrote:
[EMAIL PROTECTED] 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
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
