[openib-general] RMPP Requirements

[Sean Hefty]

On Wed, 04 Aug 2004 15:41:05 -0400
Hal Rosenstock <halr at voltaire.com> wrote:

> >>> 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
> 
> As long as we don't want any further checking along the lines
> I described as part of #1.

I'm not quite following this.  Which checks are you refering to?

> Assuming those checks are not done, this would
> allow a request to be sent via RMPP and it would be responded
> to even though it shouldn't be. So we would be relying on
> the requester to do the right thing. I don't think that is a good
> idea and it would get caught by a compliance test (some day).

Still not quite following you here...

> Request/response matching would occur above RMPP.

I agree that request/response matching needs to be above RMPP.

> >>> 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 still don't see how that handles the 2 sided transfer. Is a 
> 2 sided transfer just a RMPP send followed by RMPP receive ?

That's my understanding.  (I'm not even sure why the spec bothered defining the startup scenarios.  I don't think that they have any effect on the data seen on the wire.)

> Wouldn't this have to be on the same context (transaction ID, etc. tuple) 
> at a minimum ? That's the significance of the IsDS flag.

I think we should focus on what's in the MAD itself.  E.g. IsDS isn't part of the RMPP header.  The context should be able to be limited to the TID.

> There are some defaults supplied in the spec (different from 2 seconds)
>  for when there is no GS class agent (no ClassPortInfo) and for ttime. 
> Should we only support the default or allow for better timeouts ?

I'm not really sure of the issue here.  If the clients can set a timeout value, then how they come up with that value shouldn't matter.  Are you suggesting that the client should provide multiple timeout values?
 
> > Clients can set the RRespTime directly in the RMPP packet.  
> 
> That's good. We might want to help with an encoding routine for this.

I agree that we can always add some helper routines in later as needed.
 
> > The access layer should only need to
> > worry about modifying things like the SegmentNumber and
> > PayloadLength.     
> 
> Wouldn't the response and transaction time outs occur within RMPP ?

Given that the spec gives us something like:

total transaction time =
4.096 us x payloadlen/220 x (2^packetlife_send_to_recv + 2^packetlife_recv_to_send + 2^recv_resp_time + 2^send_RMPP_resp) x 8 because we want a bigger value

And trying to calculate this actual timeout involves sending a bunch of queries to the SA, I'm inclined to say, let's just do something really simple.