Tung, Chien Tin wrote:
But the IB and IW port space is _already_ merged by the RDMA_CM.  That's
my point.  So a solution that breaks this impacts transport-independent
applications that use the rdma cm...

Could we prove a strong need for that short-cut?
If its really needed, one global RDMA_CM instance should be able
to achive that requirement. But wouldn't that go together with a waste
of unused transports resources (i.e., IB binds would create
and bind also TCP sockets..?).

My comment has nothing to do with TCP ports but rather RDMA ports as
abstracted by the RDMA_CM.  The RDMA_PS_TCP port space is shared among
all the RDMA transports.  So if you rdma_bind() to port space
RDMA_PS_TCP, addr INADDR_ANY, port 9999, then it will bind the cm_id to
all IB and IW providers for that address/port (note the providers don't
really get called until rdma_listen()).  Thus if you propose moving the
bind operation down into the device providers, then the IB providers
will also have to add this logic.  Or some solution must be defined to
keep the IB and IW port spaces common.  Otherwise the RDMA_CM cannot
support transport independent applications...

I didn't think about this before, a bit too focused on solving the iWARP side.
Bernard, what about letting RDMA CM allocate the socket and exposing it to softiWARP?


We don't want the RDMA CM allocating sockets. That won't fly upstream eh? Unless we have a provider attribute or something that tells the RDMA CM that this provider uses a host socket. And this might really need to go into the IWCM...





--
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

Reply via email to