> > Have you had a chance to look more into the above for fork() support?
Well, the good news is that fork support is possible under some limitations. I have a modified version of librspreload that hooks fork and transitions the last accepted connection from a normal socket to an rsocket. (This was just an easy test to see what problems would pop up.) I added a fork option to rstream to test, and it does work. (And there was much rejoicing.) There are some issues. One is that if any IB resources are allocated before fork is called, there doesn't seem to be any way for the child process to remove them without affecting the parent process. I had to change how the librdmacm allocated and freed protection domains to work around this, which worked for rstream, but may not work for all apps. What's needed is a way for a child process to close IB resources that it won't use (in order to free up memory), but doesn't result in destroying the kernel resources. I believe such a feature may also help applications that want to use checkpoint/restart. Another issue is handling errors and falling back to the normal socket when the rsocket connection attempt fails. Fork ends up needing to exchange messages on the normal socket for synchronization purposes, which changes the user's protocol. But I think we can come up with a way to support fallback under most circumstances. The bad news is that what I have was too limited to work with the next app that I tested (netperf)... Changes needed to handle it appear possible, just more involved. (And there was much gnashing of teeth.) - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
