>> We do have unregister on finalization. But this code doesn't introduce any >> synchronization across processes on the same node, since kernel manages the >> receive qp. If the reference counter will be moved to app responsibility, it >> will enforce the app to mange the reference counter on app level , in other >> words , it will require some process to be responsible for the QP. In context >> of MPI-2 dynamics, such approach will make MPI community live much more >> complicated. > > I'm not sure we're fully communicating here. I understand the usage model > for xrc.
Ok. > > The basic problem is determining the lifetime of the xrc target qp. One > process creates the xrc target qp. A process also owns connecting the target > qp. Any process can create the xrc domain. If the target QP is opened in low level driver, then it's owned by group of processes that share the same XRC domain. And , as I mentioned in the reply to Jack, I totally agree that maximum life time of target QP is bound to XRC domain life time, even so it should be a way to destroy the QP before XRC domain distraction. My main point is that the target qp should be maintained by low level driver and not specific MPI process (like send qp) Regards, Pasha-- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
