[openib-general] kDAPL: ready for gen2/trunk/ inclusion?

[Caitlin Bestler]

I believe that the EVD is an extremely valuable feature, but
I do agree that is one that should be optional to use.

That is why I believe there needs to be a transport neutral
API that is lower than kDAPL. However I believe that such
an API should be cleanly separated from kDAPL so that
it does not cause confusion for developers.

There are two basic approaches to this:

a) define a subset of kDAPL that provides only transport
    neutrality and none of the "extra" features such as EVDs.
    Then provide an open source implementation of the missing
    features written on top of the core API.

b) define a verb layer interface that is usable by kDAPL, other
   middleware and advanced applications. Implement kDAPL
   and other middleware using it.


Both are starting from an existing interface. A is working down
from kDAPL. B is working up from gen2. Either works. My 
current estimation is that B is easier. But I don't see any
point in doing both.


On 7/14/05, Christoph Hellwig <hch at lst.de> wrote:
> On Thu, Jul 14, 2005 at 02:04:52PM -0400, James Lentini wrote:
> >
> > When the DAT Collaborative solicited requirements for their API, RDMA
> > consumers requested this feature. The idea is that a single
> > event source is a cleaner, simpler programming model.
> 
> The DAT Collaborative is responsible for all that mesß so I don't take
> them serious at all.  If you feel so strongly about this feature
> implement it ontop of the new rdma stack and we can see whether it makes
> the clients simpler or more complex.
> 
> _______________________________________________
> 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
>