Hal Rosenstock wrote:
Hi Sean,
I just started playing with RMPP and have one comment and a couple of questions. I am just doing some preliminary testing with SA GetTable/GetTableResp.
1. I see a NWL in some ACKs of 0x41 when ACKing segment 1. So the receive side supports 64 incoming MADs. Is that correct ? (That seems good to me).
This is set in the call window_size(). The window size is set to the size of the QP >> 3. I made this value up.
2. Since RMPP supports streaming (I know OpenIB doesn't do this on transmit), what does the receiver do with an incoming RMPP stream whose PayloadLength is not specified in the FIRST DATA packet ? (I think this may be needed for interoperability with third party RMPP implementations which do this).
The RMPP receive code doesn't use the FIRST payload length when receiving data. It looks for the LAST bit to be set in the incoming data MAD.
Also, if you can think of a way to support this on the send side, you/I/someone could add this. I think that this would require extending the send MAD API.
3. How does the RMPP receiver handle discrepancies between the FIRST DATA PayloadLength and the LAST DATA PayloadLength ?
Currently it doesn't. The payload length in the LAST data packet is used to calculate the padding for the total MAD length. See get_mad_len(). The only check that's done is to ensure that the calculated padding is smaller than the MAD's data size.
- Sean
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
