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

[Caitlin Bestler]

On 7/14/05, Sean Hefty <mshefty at ichips.intel.com> wrote:
> James Lentini wrote:
> >
> > The benefit is that all RDMA related events are produced by the same
> > source.
> 
> I understand what it does.  But why is that a benefit?  It restricts clients
> from setting event handling priorities.
> 
> > Consumers would be
> > better off handling the work completions and callbacks directly.
> 
> Exactly.  What makes this handling so difficult that it needs to be abstracted?
> 

There are two important features of the EVD, even in KDAPL callback mode,
that were considered crucial by all of the early participants. These were based
on very negative experiences working with VIPL that lacked these features:

1) unifornmity. The application does not have to deal with one rule for the CQ,
    one for Connection Establishment, one for asynch affiliated events, one for
   asynch unaffilliated events, and one for IPC.

2) serialization: The application does not have to worry that an asynch event
    will interrupt the processing of a work completion, or vise versa.
Or whether
   affilliated, unaffilliated and  connection management events come from one,
   two or three sources.

I'd to re-iterate that this was based on feedback of people developing
applications to run in kernel mode based on actual problems they had
experienced with prior APIs such as VIPL -- not abstract theory.