Think of a single API that supports iWARP and IB (transport independent API). To a connection listener it provides the IP 5-tuple + private data. For IB it means that CM parses REQ and extracts IP 5-tuple as separate fields from private data. Listener does not parse the private data encoding of the proposal.
So CM need to know if it need to encode IP 5-tuple on requestor side and if need to parse on responder side. Arkady Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance phone: 781-768-5395 375 Totten Pond Rd. Fax: 781-895-1195 Waltham, MA 02451-2010 central phone: 781-768-5300 > -----Original Message----- > From: Sean Hefty [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 1:08 PM > To: Kanevsky, Arkady > Cc: Caitlin Bestler; [EMAIL PROTECTED]; > [email protected]; [EMAIL PROTECTED] > Subject: Re: [openib-general] RE: [dat-discussions] round 2 - > proposal for socket based connection model > > > Kanevsky, Arkady wrote: > > Correct. > > But this does bring the question how responder CM knows > that it need > > to parse the private data. I suspect this will be done via > new version > > of CM. But a suage of some of the CM REQ reserved fields are also > > possible. Anotherwords the current CM version assumes that CM only > > supports one version and there is no need to support more than 1 > > version. > > The responder knows how to parse the private data based on > the service ID that > they're listening on. This is how it's done today, and how > it will still need > to be done. What is the motivation to change it? > > What data is beyond the addressing? How does the responder > know how to > interpret that? > > - 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
