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
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
