[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