> From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 20, 2005 11:11 AM > > Fab Tillier wrote: > > I would personally rather see a reserved bit get used. > > Imagine a system that has two protocols installed that > > use IP addressing. That system might want to have different > > apps listening on the same port number over both, even though > > the protocols are different. > > I don't think that this maps well to TCP. Apps need to listen on > different ports.
Are DAPL apps TCP apps? I thought they just wanted to use IP addresses for connection establishment, but weren't actual TCP apps. If DAPL apps aren't TCP apps, should they block usage of the TCP port from real TCP apps? > > Having a reserved bit in the REQ indicate the presence of IP > > addressing information (including source and destination port > > numbers) in the private data seems most flexible to me. > > How would a reserved bit help here? How does the CM know which > app to give the request to? Based on the ServiceID provided by the applications on both sides of the connection. > My preference is to use the service ID, with a mapping that looks like: > > (OPENIB_OUI << 48) + port number > > because that makes my job easier. :) I think having a range of service IDs defined for TCP applications makes sense. So for TCP apps, the port number would be encapsulated in the SID as you suggest, and non-TCP apps that want to use IP addresses for connection establishment wouldn't care about ports and would use their own SID. This eliminates the need to put the port numbers in the private data - only the source and destination IP addresses. - Fab _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
