Hi Sean, Here are some wire based observations so far on RMPP running between a toy SA client (making some GetTable requests) and OpenSM with RMPP enabled:
Short RMPP messages (less than 1 MAD's worth) have first bit set but not also last in RMPPFlags. 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. 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. 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. 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 ? Thanks. -- Hal _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general