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

[Rimmer, Todd]

I haven't been watching this thread so I might be missing the point.

> -----Original Message-----
> From: openib-general-bounces at openib.org
> [mailto:openib-general-bounces at openib.org]On Behalf Of Hal Rosenstock
> Sent: Tuesday, April 11, 2006 12:48 PM
> 
> On Tue, 2006-04-11 at 12:38, Sean Hefty wrote:
> > Hal Rosenstock wrote:
> > > I don't think that can work. If the request and response 
> are RMPP'd, I
> > > think a direction switch is needed so this can't be done.
> > 
> > A direction switch is only needed if we want to follow the 
> DS RMPP protocol. 
> > Why can't both sides just follow the sender-initiated 
> protocol instead?  
> 
> In thinking about this a little, I see no reason this 
> couldn't work. In
> fact, that's one mode I have toyed with (a non conformant SA GetMulti*
> mode) in developing SA MultiPathRecord.

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.

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.

Hence perhaps the complexity of a compliant double sided solution could even be avoided for now.

Todd Rimmer