Rimmer, Todd wrote:
It is a bad idea to implement a custom double sided approach. This will suddenly create various compliance and interop issues. For example Windows Open Fabrics and Linux OpenSM might not interoperate. Not to mention other OSs (such as Solaris) which have their own IB stacks.
My proposal is that the spec be updated to limit DS RMPP to SA GetMulti only, which is the only thing it is currently defined for. A vendor specific class that required RMPP requests followed by RMPP responses would be defined to use two sender-initiated transfers. Currently, such vendor transactions are undefined.
As a second proposal, remove DS RMPP from the spec.
More interestingly, it is very likely that most uses of getmulti would involve a requestor providing a request which would fit into a single MAD packet and the RMPP protocol would not be fully needed by the sender (eg. just the simple case of a single packet RMPP transfer by sender with a multipacket RMPP response). You will note up to 10 GIDs can fit in the request within a single packet. The most common uses will probably involve 2 source GIDs and 2 destination GIDs.
Whether the request fits into a single MAD or not, the DS RMPP protocol is supposed to be invoked. Meaning that an ACK is sent, and an ACK of that ACK is also generated. The implementation difficulty lies in maintaining the context of the DS RMPP transaction on the receiving side, not the segmentation and reassembly.
Hence perhaps the complexity of a compliant double sided solution could even be avoided for now.
Right now, an RMPP request followed by an RMPP response works, but it isn't compliant with the DS RMPP protocol. It is compliant to using two sender-initiated transfers.
- Sean _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
