On Wed, 2006-08-16 at 14:29 -0700, Sean Hefty wrote: > Pete Wyckoff wrote: > > 1) When a device gets added to the system, is there code that applies > > existing INADDR_ANY listens to the new device? Where? > > Yes - see cma_add_one() where cma_listen_on_dev() is called. > > > By the way, shouldn't the rdma_bind_addr call that preceeded > > rdma_listen have failed when I tried to bind to INADDR_ANY with a > > specified port, but that port was already in use by a device? This > > could be just another failure to keep the amso NIC state consistent > > with the host state. > > My expectation is that an iWarp device would fail the bind. > > In general, I do not believe that the correct approach is for the RDMA CM to > use > the same port space as TCP. Underlying transports should map addresses in > whatever way works best for them. For IB, the IP addresses are mapped to > GIDs > and ports to service IDs. iWarp should map into the correct port space or > fail > the binding.
I think this makes sense for IB, however, for TCP based transports, we should share the port space with TCP. The reason is that most RNIC's are "converged nic" implementations. That is, the RDMA side and non-rdma side both share the same IP address (Ammasso had mac addresses which made it look like two physical ports to the native stack). In the current model, if an application does a listen over the native stack and then does an rdma_listen, BOTH will succeed, however, after the rdma_listen, the native side will never see the connection requests! This is clearly busted. Back to the IB side, the port space management services that I have in mind would allow you to create your own IB port space, SDP port space, etc... that is separate from TCP, just like UDP and TCP are different. Plus it would handle reuseaddr consistently, integrate with netstat, etc... Even if we never do it for IB, I think we need it for iWARP... > > - Sean > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
