Or Gerlitz wrote:
Sean Hefty wrote:
I thought about that, but didn't know whether it was in use. I agree
that
existing apps shouldn't break. (I was thinking more along the lines
of adding a
new call that would make this behavior explicit, but haven't taken
the time to
really study the details.)
Yes, lets not break existing apps such as stgt. I'm fine with adding
new call.
Or maybe map PS_TCP port space to the be the unified space, and have a
new PS_RDMA or PS_IB port space that doesn't?
Does anyone know if a kernel patch to fix this has been accepted
directly into
the distros?
Sorry, but I wasn't sure to follow what you mean by "fix this" ... did
you refer to kernel apps that don't use different port numbers for
their TCP vs RDMA listeners, or you referred to the rdma_cm patch
which is not merged into mainline?
I haven't pushed to get a distro to pull in the cma patch. I assumed
since it wasn't destined for upstream, that they wouldn't accept it.
Also, does anything keep MPI from doing exactly what we're discussing
in the
application as part of using the librdmacm? (Besides having all apps
duplicate this
no, nothing prevents an app to open/bound a socket as long as the port
is available and its ulimit allow to open the number of sockets it
wants. This actually somehow brings me back to square one with regard
to the actual problem, so I'll ask you guys a question as a reply to
earlier post on this thread...
Nothing prevents this, but why force OpenMPI, MVAPICH2, HP MPI, Intel
MPI, and Scali MPI to all do this?
Steve.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
