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

[Hal Rosenstock]

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.

> I don't see where this is prohibited, and we know that it works.

It's not prohibited. I'm not sure there are many explicit compliances
related to RMPP.

> > I don't think the issue is gain but how to reverse the RMPP roles. When
> > you say 2 individual sender initiated transfers, would they have the
> > same transaction ID ?
> 
> Yes.
> 
> All we're trying to accomplish is reliable segmentation and reassembly.  IMO, 
> the RMPP start-up scenarios are utter nonsense.

The two one sided transfers still need to do those things so this is a
general RMPP comment rather than a DS one.

> (Wow, I'm almost beginning to sound like a Linux programmer now.)

I think you qualify :-)

>   But given that its defined in the spec, and 
> SA GetMulti is defined to use it, let's limit its use to that method.
> 
> >>If we want to support DS RMPP for more than just MultiPathRecord, it seems that 
> >>we need some sort of class/method mapping,
> > 
> > 
> > maybe attribute ID as well.
> > 
> > 
> >> which would require changing the kernel MAD API.
> > 
> > 
> > Yes unless this were somehow made self-identifying (part of the RMPP
> > protocol rather than an internal state variable).
> 
> If we're going to change the RMPP protocol, my vote is to remove DS RMPP 
> entirely, unless someone can show why the additional complexity is needed.

There is backward compatibility at a minimum. I'm exploring more on
this.

-- Hal