What if each cm_id has its own fd? Then they could be associated with a channel, which is just an object that tracks which fds are in the channel and uses select()/poll() on the entire set of fds for rdma_get_cm_event().
Hmm... I'll give this some thought. This might change the kernel ABI, but would affect the library ABI (which exposes the event channel fd), bumping the major version. I don't know without doing some research how to handle new connection requests, but that should be possible.
So moving a cm_id to another channel is simple and doesn't involve moving the events since they will be queued on the cm_id's fd. You just move the fd from one channel to another and events keep flowing as normal...
We still need to handle the window where an event is pulled from one channel immediately before the cm_id is migrated to a new channel. Maybe we do this through documentation, but it would be nice to have the interface behave in a way that's easy to program to. (I don't think an fd per cm_id makes this any more difficult.)
What I did finally find was a kernel call fget(fd) that at least seems to be usable for what I need.
- Sean _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
