On Sat, 9 Jun 2012, Hefty, Sean wrote:
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.
Yeah..I looked a bit inot it. It seems easy enough to, within this restricted
paradigm, to use shared memory for the data buffer and share it between the
parent and the child. The QP/CQ accesses are not that straightforward and I
need to understand more before I can suggest anything myself.
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.
yes.
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.
Though one can consider the fall-back in reverse order i.e. if the
rdma connection fails continue with the already established connection (over
the normal inet socket).
Vivek
- 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
