[openib-general] Re: Dual Sided RMPP Support as well as OpenSMImplications

[Sean Hefty]

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