Arlin> Yes, this is certainly another option; albeit one that
Arlin> requires more system resources. Why not take full advantage
Arlin> of the FD resource we already have? It's your call, but
Arlin> uDAPL and other multi-thread applications could make good
Arlin> use of a wakeup feature with these event interfaces. An
Arlin> event model that allows users to create events and get
Arlin> events but requires them to use side band mechanisms to
Arlin> trigger the event seems incomplete to me.
I disagree. Right now the CQ FD is a pretty clean concept: you read
CQ events out of it. If you want to trigger a CQ event, then you
could post a work request to a QP that generates a completion event.
Adding a new system call for queuing synthetic events seems like
growing an ugly wart to me.
If we look at the analogous design of a multi-threaded network server,
where a thread might block waiting for input on a socket, we see that
there's no system call to inject synthetic data into a network socket.
I'd rather fix the uDAPL design instead of adding ugliness to the
kernel to work around it.
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.
Mike
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
