Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > >>The other problem is that DS RMPP requires maintaining state between > >>receiving a request and the generation of a response. > > > > It does? Why does it? > > It needs to track receiving an ACK of the final ACK to the request, which > carries the initial window size for the response. Conceptually, what happens > is: > > -- request --> > <-- ACK request -- > -- ACK (response window) --> > <-- response -- > -- ACK response ->
OK, so apparently, what we have with dual-sided, after ack with response window arrives, is a sender that can't send data since userspace did not give us the response. I see how this approach would require significant change in core, and I'm not really happy with this. Here's an alternative idea: instead of making huge changes all over, how about we delay passing the RMPP transaction up to the user until we have the ACK with the response window, and ask the user to give us back this ACK packet (or just the window?) when he sends the response? Since we didn't support dual-sided tansfers this extends rather than breaks both the ABI and the API. The issue of duplicates can then be dealt with by Jack's patch, detecting duplicate requests which does not require additional state. Sounds good? -- 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
