[openib-general] RMPP Requirements

[Sean Hefty]

On Wed, 04 Aug 2004 13:21:58 -0400
Hal Rosenstock <halr at voltaire.com> wrote:

> Hi,
> 
> Here's my cut at RMPP requirements:
> 
> - At least a flag is needed to indicate RMPP or not
> - There are 3 types of RMPP transfers:
>         - receiver initiated 
>         - sender initiated
>         - sender initiated two sided
> Perhaps this is better expressed in terms of roles:
>         - receiver role (used by SA client GetTable and GetTraceTable)
>         - sender role (used by SA GetTableResp)
>         - sender initiated two sided (used by SA client GetMulti)
> - RMPP can be used by each GS class although SA is the only one
> currently using it
> - RMPP is method and attribute specific within any class that might use
> it
>         - currently as there is no overlap with the same SA attribute
> being
> supported by multiple methods, method appears to be sufficient
> - RMPP Timeouts
>         - Response time is based on SA PathRecord:PacketLifeTime and GS
> agent
> ClassPortInfo:RespTimeValue (which can change) if one exists
>         - Total transaction time is based on SA
> PathRecord:PacketLifeTime in
> both directions, receiver's RespTimeValue, and response time above

I've started trying to incorporate RMPP into the "compromise" GSI/MAD APIs that I sent out earlier.  For RMPP, I'm hoping that the access layer can have a limited view of RMPP, while still providing all of the support that's required.  E.g.:

* The access layer needs to know if the RMPP header is in a MAD or not.  I think that this can be determined by the management class.
* It needs to know the offset of the RMPP header into the MAD.  This seems fixed for currently defined classes.
* The access layer needs to know what version of RMPP is being used.  This is given in the RMPP header, which would work, provided that the header doesn't change.

Given this, the access layer should be able to determine if RMPP is active.  I don't think it matters which of the three types of transfers are in use.