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