But the difference is who generates rtr message. It is not user job to deal with it. Thanks,
Arkady Kanevsky email: [EMAIL PROTECTED] Network Appliance Inc. phone: 781-768-5395 1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195 Waltham, MA 02451 central phone: 781-768-5300 > -----Original Message----- > From: Steve Wise [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 14, 2008 4:35 PM > To: Sean Hefty > Cc: [EMAIL PROTECTED]; [email protected]; > [EMAIL PROTECTED] > Subject: [ofa-general] Re: [PATCH] Request For Comments: > > Sean Hefty wrote: > > Thanks for looking at this. > > > > > >> Here is the top level API change I'm proposing for enabling > >> interoperable peer2peer mode for iwarp. I want to get > agreement on > >> how to expose this to the application before posting more of the > >> gritty details of the kernel driver changes needed. The plan is to > >> include this support in linux-2.6.27 + ofed-1.4. > >> > > > > I don't have a better idea what to call this, but when I > think of peer > > to peer, I think of that as the connection model, not a > channel usage restriction. > > > > > > I think I'll call it rtr_mode. That better describes it. > The client side is sending a "ready to receive" message. And > the server side holds off SQ processing until the RTR is received... > > > _______________________________________________ > general mailing list > [EMAIL PROTECTED] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > _______________________________________________ ewg mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
