> iWARP is just another protocol on top of TCP - like iSCSI. There is > no good reason to invent another TCP port maintainer per TCP user > type trying to synchonize with the kernel if the resource is host > global and already maintained by the kernel.
I think the counter-argument to this is than an iWARP offload NIC is an independent TCP stack and hence should not be tied into the host stack. It's interesting that you bring up iSCSI -- as I understand things, iSCSI offload HBAs are typically configured with their own IP, through a separate mechanism. (The port collision problem is not likely to be hit with iSCSI, since the HBA is an initiator and hence does only active connections, and a 4-tuple collision between connections to the iSCSI target is not likely and other host stack traffic is extremely unlikely) > Since we are developing and already open sourced a full software > implementation (SoftiWARP) of RDMA, our view on the optimal solution > must be different. Like kernel iSCSI, we are running on top of regular > kernel sockets. With that, there is no point having a connection manager > blocking just the port we wanted to use for communication - SoftiWARP > uses kernel sockets for data communication. I think this is an extremely strong argument against the patch that started the thread. Breaking soft iWARP seems a fatal flaw. - R. -- Roland Dreier <rola...@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
