<html>
<body>
<font size=3>At 11:11 AM 8/19/2005, Roland Dreier wrote:<br>
<blockquote type=cite class=cite cite=""> Arlin>
Yes, this is certainly another option; albeit one that<br>
Arlin> requires more system resources. Why not take
full advantage<br>
Arlin> of the FD resource we already have? It's
your call, but<br>
Arlin> uDAPL and other multi-thread applications
could make good<br>
Arlin> use of a wakeup feature with these event
interfaces. An<br>
Arlin> event model that allows users to create
events and get<br>
Arlin> events but requires them to use side band
mechanisms to<br>
Arlin> trigger the event seems incomplete to
me.<br><br>
I disagree. Right now the CQ FD is a pretty clean concept: you
read<br>
CQ events out of it. If you want to trigger a CQ event, then
you<br>
could post a work request to a QP that generates a completion event.<br>
Adding a new system call for queuing synthetic events seems like<br>
growing an ugly wart to me.<br><br>
If we look at the analogous design of a multi-threaded network
server,<br>
where a thread might block waiting for input on a socket, we see
that<br>
there's no system call to inject synthetic data into a network
socket.<br><br>
I'd rather fix the uDAPL design instead of adding ugliness to the<br>
kernel to work around it.</blockquote><br>
Please take a look at the Sockets API Extensions standard that was
published quite awhile back to insure that the infrastructure can support
this API as well. The API was developed by a set of Sockets
developers and addresses a number of concerns for async communications,
event management, explicit memory management, etc. It is also well
suited to have SDP transparently implemented underneath it.<br><br>
Mike</font></body>
</html>