On 5/3/05, Andy Isaacson <[EMAIL PROTECTED]> wrote: > > A consistent statement would be > > After fork(2), any regions which were registered are UNDEFINED. > Region boundaries are byte-accurate; a registration can cover just > part of a page, in which case the non-registered part of the page > has normal fork COW semantics. >
That is a reasonable approach. > > Obviously, calling *any* RDMA-userland-stuff in the child is completely > undefined [1]. One place where I can see a potential problem is in > atexit()-type handlers registered by the RDMA library. Since those > aren't performance-critical they can and should do sanity checks with > getpid() and/or checking with the kernel driver. > That is also reasonable. None of the RDMA libraries I have worked on bothered to use an atexit()-type hook because the user was theoretically *required* to close the rnic, and driver code was already reuqired to clean up in case of a total process failure. Adding an intermediate safety-net for applications that exited cleanly but forget to close just didn't seem worthwhile. If the application wants the cleanup performed optimally then it can close the rnic, otherwise it can't complain about forcing the RNIC vendor to clean up in the driver code. > [1] You might want to allow the child to start a completely new RDMA > context, but I don't see that as necessary. > That should be allowed. It is actually more normal to use the parent as a dispatcher and to actually manage the connection in a child process. _______________________________________________ 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