[ofa-general] Re: [PATCH] Request For Comments:

[Kanevsky, Arkady]

But the difference is who generates rtr message.
It is not user job to deal with it.
Thanks,

Arkady Kanevsky                       email: arkady at netapp.com
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:swise at opengridcomputing.com] 
> Sent: Wednesday, May 14, 2008 4:35 PM
> To: Sean Hefty
> Cc: rdreier at cisco.com; ewg at lists.openfabrics.org; 
> general at lists.openfabrics.org
> 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
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
>