[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

[Caitlin Bestler]

The need for a single unifying event disptaching method was *the*
primary feedback received from VIA user when DAPL started.
That included both kernel and user-mode applications, in fact
one of the primary reasons why the DAT Collaborative was
started was that there was no unrestricted API for VIA that
could be used in the kernel.

As I stated earlier, kDAPL is designed for *applications*
and was not really intended for use by the OS itself.
As such it abstracts more than just the transport.

If you wrip out the EVDs it isn't really "kDAPL" anymore.
Having a stripped subset of kDAPL with a clearly different
name that is *only* what is needed to abstract transport
differences might be a really neat idea, and having it
be otherwise compatible with kDAPL would also be good.

But I'd suggest understanding why something is present
before ripping it out. EVDs are there precisely because
dealing with multiple callbacks and completion queues
was universally found to be unwieldly and unfriendly
to application developers.

On 5/31/05, Libor Michalek <libor at topspin.com> wrote:

> 
>   Well, from a kernel API design philosophy the evd is somewhat odd.
> The whole idea behind the event model seems a bit convoluted. First
> multiplex a wide variety of events from the provider into a single event
> queue, and then have an API so the consumer can tell what type of event
> they actually have and can still receive the event notification in the
> provider's context.
> 
>   This seems to be a lot of work to first hide useful information, but
> also not loose the information in case the consumer really does want it.
> It appears to be a case of a decent userspace idea that doesn't make
> much sense in the kernel. Why is it there? I imagine it's to abstract a
> variety of OS kernels, which was one of the goals of the design.
> 
>   Also, I realize it's just an implementation detail, but I've got a
> number of issues with ATS.
> 
> 
> -Libor
> _______________________________________________
> 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
>