[openib-general] Re: [swg] Re: private data...

James Lentini jlentini at netapp.com
Thu Oct 20 11:39:24 PDT 2005



On Thu, 20 Oct 2005, Fab Tillier wrote:

> > From: Sean Hefty [mailto:mshefty at ichips.intel.com]
> > 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 understand what you mean by this. Do you want two apps 
listening on the same service id?

> > I don't think that this maps well to TCP.  Apps need to listen on
> > different ports.
> 
> Are DAPL apps TCP apps?  

DAPL doesn't mandate any particular network transport. However the API 
uses sockaddrs to hold network addresses. The specification says that 
these should contain IP addresses.

> 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?

They should not.

> > > 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.

You'd need to add a parameter to specify whether or not the bit should 
be set to the call for listening on a service id, right?

I like Sean's idea better. Have a well know service id or range of 
service ids on which this protocol is used. I think of it as a service 
running on top of the CM protocol for using IP addresses on native IB. 
I don't think it should be mandatory for every CM connection.

james



More information about the general mailing list