[openib-general] RMPP Requirements

[Sean Hefty]

On Wed, 04 Aug 2004 14:12:14 -0400
Hal Rosenstock <halr at voltaire.com> wrote:

> Sean Hefty wrote:
> > * 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.
> 
> Not sure what you mean by "determined by the management class".
> I think it is at a minimum class and method (at least for SA today).

13.6.2.1. If a management class uses RMPP, it shall include the RMPP header...in every MAD of that class type.

> > * It needs to know the offset of the RMPP header into the MAD.  This
> > seems fixed for currently defined classes.
> 
> It is fixed for all classes using RMPP. Not sure what you mean by currently
> defined classes.

I was referring to vendor-defined classes, versus classes defined in the spec.

> > * 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.
> 
> I don't think the position of the version in the header can change without
> the
> base version changing. That's not likely any time soon :-)

Didn't they change the MAD header from 1.0 to 1.1 without changing the version?  Hmm... maybe we can't even trust the version number then...

> > Given this, the access layer should be able to determine if RMPP is
> > active.
> 
> Sure the RMPPFlags,Active can be checked. On the responder side,
> do we want to make sure that RMPP is allowed/supported on that class/method
> and possibly attribute ?

I would think the checks on a receive would be:
1) do we have someone to give this to
2) did the receiver tell us to look for an RMPP header
3) is RMPP active in the received MAD
4) invoke RMPP handling

Checks for send would be:
1) did the sender indicate there's an RMPP header in his MADs
2) is RMPP active in the MAD to send
3) invoke RMPP transfer

> > I don't think it matters which of the three types of transfers are in use.
> 
> I'm not quite with you yet on this. I can see it for sender and receiver but
> doesn't someone have to indicate a 2 sided transfer ? Where/how do you see
> that being handled ?

I think that the checks listed above are sufficient.

> I think timeouts need some exposure through the API somehow. In order to
> handle the transaction timeout properly, it appears that the packet lifetime
> in both directions needs to be obtained (passed in ?). It also appears that
> in order to set the response time properly access to the
> ClassPortInfo:RespTimeValue is needed (which may change) if present.

I need to think about this more.  My thought is that the client needs to determine the appropriate timeout, either through queries or by using 2 seconds as a nice number.  Clients can set the RRespTime directly in the RMPP packet.  The access layer should only need to worry about modifying things like the SegmentNumber and PayloadLength.