Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>: > Subject: Re: RFC: detecting duplicate MAD requests > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > Subject: Re: RFC: detecting duplicate MAD requests > > > > On Wed, 2006-06-14 at 17:22, Michael S. Tsirkin wrote: > > > Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > > > > Subject: Re: RFC: detecting duplicate MAD requests > > > > > > > > Michael S. Tsirkin wrote: > > > > >>We're kind of left with the same issue of trying to determine if a > > > > >>received > > > > >>MAD will generate a response. > > > > > > > > > > > > > > > How do you mean? We have IsDS=1 flag for dual-sided, don't we? > > > > > Dual-sided > > > > > transfer always has a response, doesn't it? > > > > > > I mean, the flag in the application that says that the transfer is > > > dual-sided. > > > The spec seems to imply that user can figure *from the method* that > > > IsDS=1, so I > > > assume users will have this logic: > > > > > > "2) > > > Begin the initial transfer by starting the send operation at the point > > > labelled > > > Send. The method or other indication should be interpreted on > > > the other side as initiating a double-sided transfer, causing the receive > > > context to set IsDS=1." > > > > > > > > > So why does the MAD layer care whether a received MAD will generate a > > > resonse? A request arrives - we pass it up. Now the ACK for the direction > > > switch arrives - we pass it up too, application should be waiting for it, > > > it > > > should take the window and pass the response back to us. > > > > The ACKs are transparent to the application/user. > > Well the ACK for the direction switch is special, isn't it? > All I'm saying, let's pass it up to the application.
I suggest a rule along the lines of "if an ACK arrives with segment number of 0 this means sender is requesting dual sided RMPP, pass it up to the application". What's the problem with this approach? I think this does not break existing apps since these don't do DS RMPP and so never get such an ACK. Right? -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
