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

Sean Hefty mshefty at ichips.intel.com
Tue Apr 11 09:38:35 PDT 2006


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?  I don't 
see where this is prohibited, and we know that it works.

> 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.  (Wow, I'm almost beginning to 
sound like a Linux programmer now.)  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.

- Sean



More information about the general mailing list