> But to map standard networking applications to rsockets we will run into the > above problem i.e. fork() will not work. It would be very useful to > allow for the standard networking paradigm of: bind()->listen()->accept()- > ->fork(), and then the server goes back to accept(). That would allow us to > use rsockets transparently with existing applications.
I'm aware that fork() support does not work. The problems lie within the RDMA stack, and maybe there's some way around this, but I'm not sure what it would be at this point. I can't say that I fully grasp all the low level issues involved in 'fixing' it. > Is it possible to support fork() for this standard model where the parent > closes its copy of the newly created socket and goes back to waiting on the > original socket in accept, and the child continues with the newly created > socket? IMO, it seems that if we can limit the usage model to what you're describing, then we may at least have a chance at supporting fork(). > Have you considered some other options to make this happen? > > Could we skip creating the endpoint in raccept(), but actually create the > new endpoint during the frist receive or send? This would then allow the > fork() to occur without the complications with the pinned data. That's an interesting possibility. I need to give something like this more thought, but establishing a connection over a normal socket, then using that to migrate communication to a QP on the first data exchange may allow for fork support. That would have an effect on trying to handle fallback support (i.e. using standard sockets when RDMA fails), plus may have other issues, but there may some be ideas here worth considering. - 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
