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

[James Lentini]

I did some research on the first topic. The unified event model was 
designed based on user feedback. User's of previous RDMA APIs found 
multiple event streams difficult to manage. They wanted the ability to 
have a single event stream that maintained ordering guarantees.

DAPL allows users to have separate event dispatchers (EVDs) for 
different event types. So if you wanted to have connection events 
seperate from data transfer event, you can do that.

Here's a little background on your second issue for those who aren't 
familiar with DAPL: To translate IP addresses to GIDs, the original 
reference implementation of DAPL looked up these mappings in the SA 
database. This implementation was dubbed ATS (Address Translation 
Service).

ATS is only one possible way to implement this. Other methods could be 
used.

On Tue, 31 May 2005, Libor Michalek wrote:

> On Tue, May 31, 2005 at 02:03:06PM -0700, Tom Duffy wrote:
>> On Sat, 2005-05-28 at 09:13 +0200, Christoph Hellwig wrote:
>>> On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote:
>>>> kDAPL is intended as a kernel-level API
>>>> for RDMA enabled fabrics. As it was initially written,
>>>> it does not meet the Linux coding style and that is why
>>>> it is being totally reworked as we speak to meet that goal.
>>>
>>> The codingstyle alone isn't the problem.  The whole design philosophy
>>> is rather odd.
>>
>> As one of the people trying to clean up kDAPL, I would like to know what
>> you think, from a design philosophy, is wrong with it.  We *can* correct
>> any daim bramaged parts.
>
>  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
>