DAPL also strip this private data header and present to Consumer IP addresses and ports as separate items from Consumer private data.
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: Tom Tucker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 5:52 PM > To: Ted H. Kim > Cc: [EMAIL PROTECTED]; openib-general > Subject: Re: [swg] Re: [openib-general] TCP/IP connection > service over IB > > > On Tue, 2005-10-25 at 13:16 -0700, Ted H. Kim wrote: > > Tom, > > > > Some comments inline ... > > > > > > Tom Tucker wrote: > > > I think it's relevant, so let's make sure my assumptions are > > > correct: > > > > > > - The ITAPI will be a "ULP" on OpenIB > > > > ITAPI is like uDAPL, so if uDAPL is a "ULP" then the answer is yes. > > The point is that for uDAPL you have the actual "app" running over > > uDAPL. So I guess it's a matter of terminology whether > uDAPL is a ULP > > or is it some sort of middleware with the app being the "ULP". > > > > Yeah, you're right the terminology is probably a little > goofy. The reason for the goofosity is that some of the "ulp" > really are protocols (ISER, IPoIB), and some are API (DAPL, > MPI). All use the same interface > to register with OpenIB. > > But that said, yes, ITAPI is like uDAPL. > > > > > > - The ITAPI will create the IRD/ORD headers in its > private data and > > > submit this as part of its connection establishment. > > > - The ITAPI consumer at the remote peer will use this data to > > > configure it's local QP before accepting the connection > > > > > > Over IB, the IRD/ORD private data will be prepended with > a "private > > > data header" that contains the source and destination IP > addresses, > > > source port, etc... The remote peer will not see this > data as part > > > of the private data, but rather will see it in the CMA > event in the > > > upcall. > > > > Over IB, the IRD/ORD data is already built in to the > standard CM stuff > > (i.e. the "responder resources" and "initiator depth" fields of REQ > > and REP). So no additional demands are made on private data > for IB in > > ITAPI for the IOH purpose. Of course the ITAPI app (like a > uDAPL app) > > can also use private data for app specific/ULP reasons. > > ok -- bad example. Sorry. This is a weird one. On iWARP, you > need the private data header to pass this stuff along and on > IB, you don't. What I was trying to say is that "whatever the > private data", on IB it will get a private data header > prepended and on iWARP, it won't. > > > > > > > > Over iWARP/MPA, there will be nothing else in the private data > > > except what was provided by the consumer (ITAPI in this > case). The > > > reason being that this extra information (IP addressing > info) is in > > > the protocol header proper. > > > > Just to restate for clarity, ITAPI for iWARP will use the first 16 > > bytes of MPA private date for the IOH (IRD/ORD header). The rest is > > usable for app/ULP reasons. > > Yessir. And in fact, the ITAPI CM will strip this stuff > before presenting it to the app. > > > > > > > I should point out that there was once a proposal of doing > a RDDP IETF > > draft which would have sub-divided the MPA private data into a > > "middleware" section and an "app" section. The idea was to be sure > > that the app/ULP and middleware (e.g. the IOH) uses of private data > > would not step on each other. I think this idea did not progress, > > mostly because the author (John Carrier, formerly of > Adaptec) changed > > jobs and was no longer working on iWARP stuff. > > > > While not directly proposed, this idea could have been > carried over to > > IB. Some of the ideas on this thread are already implicitly > doing this > > middleware (for IP addressing purpose) vs ULP/app split. > > > > I think we are grappling with a lot of these layering issues > now. We are also grappling with protocol vs. implementation issues. > > Keep it coming, because this is exactly the kind of feedback > I think we need. > > > -ted > > > _______________________________________________ > 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
