[ofa-general] librdmacm feature request

[Sean Hefty]

> 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