[openib-general] gen2/rnic-pi differences

Caitlin Bestler caitlin.bestler at gmail.com
Fri Jul 1 09:53:06 PDT 2005


On 7/1/05, Sean Hefty <mshefty at ichips.intel.com> 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.



More information about the general mailing list