[EMAIL PROTECTED] wrote: > Tom Tucker wrote: >> I think this makes sense for IB, however, for TCP based transports, >> we should share the port space with TCP. > > My view is that the iWarp transport needs to provide the > mapping from an RDMA_PS_TCP to the actual TCP port space, > RDMA_PS_UDP to UDP, etc. This is a function that should be > part of the transport specific code, and not the general RDMA CM code. >
I really don't see any benefit in having each iWARP device "map" from RDMA_PS_TCP to actual TCP. It translates to a TCP port for an IP address that is assigned to this host, the kernel should be the final aribiter of the usage of that TCP port. So centralizing that co-ordination with the host stack is best done at the IWCM. I also believe that the above statement is true for IP addresses uses by IPoIB, SDP and when IB connections are established using IP addresses. But the need to co-ordinate IP addresses over an InfiniBand network is admittedly a bit more theoretical. Still, the IB network should not be using IP addresses in anyway that conflicts with other uses of IP addresses on other devices, and it would be better if the host stack could actually enforce that. UDP is a totally different issue. To the best of my knowledge all iWARP device already support an unreliable datagram service that is already fully integrated with the Linux network stack: SOCK_DGRAM sockets and UDP. If there is an actual need to support UDP via a QP/CQ interface when using iWARP then that should be documented, and tradeoffs considered. For example, a software "QP" that merely used SOCK_DGRAMS is extremely easy to use as long as it does not have to share a CQ with reliable connections. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
