Just thinking out loud:
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().
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...
Steve.
Sean Hefty wrote:
The only idea I've been able to come up with for moving an rdma_cm_id
between fd's is to perform a two-step process. (The two steps would be
done by a single API call.)
1. prepare to modify(old_fd, rdma_cm_id)
Somehow mark that the rdma_cm_id will migrate to a new fd.
2. commit modify(new_fd, rdma_cm_id)
Migrates the rdma_cm_id to the new fd and moves the events.
Using two steps provides the kernel code the file context that it needs,
and should protect against the fd's being closed. The biggest hurdle to
this is ensuring that the same user owns both fd's, possibly by
validating some sort of key between the two steps. I just haven't
figured out what works as a key.
- 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
_______________________________________________
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
