On 7/1/05, Sean Hefty <[EMAIL PROTECTED]> wrote: > Caitlin Bestler wrote:
> > The assumption being made here is that there needs to be another abstraction > layer on top of the existing core layer. I don't think that an optimal > implementation would want this. > I believe that any application using the core layer directly would have the same need to identify *it's* context efficiently when processing a work completion. The QP ID does not truly meet that requirement. It is an arbitrary integer selected by another software package. You have to add your own reverse indexing or use the work request ID to fully identify your context, which means that it cannot also be promised to a higher layer. So I think this problem is generic to *any* middleware consumer, whether it is DAPL, IT-API, MPI, the communications layer of a database, RPC, etc. The Work Request ID by itself will typically leave any middleware consumer forced to create a "DTO Coookie" type solution. And while I believe that we should *allow* consumers to use the core layer directly, I do not believe we should *encourage* it. Middleware layers such as DAPL, IT-API or an MPI messaging system are enable the application to focus on application issues rather than on wire issues. That's why kDAPL has been used, and why we should be concerned with enabling efficient middleware even if we allow consumers to bypass it. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
