With the addition of getnam(), sin_port is filled in with
the reserved port number and cma_any_port will evaluate to
false and the reserved port will get used instead.
So the only problem was carving a port from the proprietary ports pool
of the rdma-cm where a port was already allocated from
Another way to look at it is, we want rdma cm to use the port reserved
by the allocated socket. V3 addressed an issue with port 0
causing rdma cm to not use the reserved port.
I was not clear in my previous email. The change is still limited to
RDMA_PS_TCP,
it does not touch other PS.
Chien Tung wrote:
RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
This is needed for iwarp providers that support native and rdma
connections over the same interface.
Optionally turned on by the new rdma_cm unify_tcp_port_space module
option.
Signed-off-by: Steve Wise [EMAIL
I understand that now the value of the port allocated by the network
stack is being kept by the rdma-cm, can you clarify what was
the outcome
of not keeping it?
The code flow for the failed case is:
1) For active open, sin_port 0 get pass in to cma_get_tcp_port().
2) The port number for the
Tung, Chien Tin wrote:
3) and calls cma_alloc_any_port() to allocate a port number which may not
correspond to the port number for the bound socket.
With the addition of getnam(), sin_port is filled in with the reserved port
number and cma_any_port will evaluate to false and the reserved port
RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
This is needed for iwarp providers that support native and rdma
connections over the same interface.
Optionally turned on by the new rdma_cm unify_tcp_port_space module
option.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
FYI: This new patch fixes a bug in my original patch, that is currently
in ofed-1.4. The bug is that the port number allocated by the stack is
not stored in the cm_id...
Chien Tung wrote:
RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
This is needed for iwarp providers that
