[openib-general] Re: Some Initial RMPP Wire Observations

Sean Hefty mshefty at ichips.intel.com
Tue May 3 13:55:55 PDT 2005


Hal Rosenstock wrote:
> Short RMPP messages (less than 1 MAD's worth) have first bit set but not
> also last in RMPPFlags.

Can you re-check this?  I'm able to successfully receive short segments, 
and the receive code looks for the last bit to check for completion.

> Also, if the initial RMPP send had bad status, that status is maintained
> in the RMPP response (ACK) by the receiver side (SA GetTable). Is this
> getting "reflected" ? Should such a send be ACKed ? Also,
> AttributeOffset is not being cleared in that ACK.

ACKs are formed by copying the headers of the received DATA MAD.  Right 
now there are minimal checks done to verify that the MADs are properly 
formatted, but adding these isn't overly difficult.

Should the AttributeOffset be cleared in the ACK?  I wouldn't have 
thought that RMPP would have changed the common MAD header information.

> In a multisegment RMPP send, the middle segments have their PayLoad
> lengths set to whatever the user initially set this to. While it should
> be ignored by the receiver, it would be better if these were sent as 0.

The spec indicates that the payload length is ignored for the middle 
segments, so I just left the field untouched.  There doesn't appear to 
be a requirement to clear it.  (Doing so is trivial if needed.)

> In the last segment, it appears that the pad is not cleared. This again
> shouldn't matter but I didn't dig out what the spec says here.

Not sure which field you're referring to here.  The payload length 
should be set to the number of valid bytes sent in the last packet.

> Is there a restriction on the message size ? Up to what size have you
> tested this ? I don't seem to get an ACK back when I send with a
> PayLoadLength of 0x6E0 but do get one with 0x370. Any idea if this is a
> problem with the sending client or a problem in the RMPP receiver code ?

There's no restriction unless there's a bug.  I've tested MADs up to 
100,000 bytes, including sending a response.  Not sure what the issue is 
that you're seeing.

- Sean



More information about the general mailing list