[openib-general] Re: Some Initial RMPP Comments and Questions

[Hal Rosenstock]

On Fri, 2005-04-29 at 12:29, Sean Hefty wrote: 
> > 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.

OK. That avoids the issue of the inconsistent FIRST length.

Wouldn't the FIRST length be useful as a hint for buffer size if present
?

> 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.

This being supporting the PayloadLength in the first DATA packet of a
send ?

> > 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.

This seems safer and avoids the inconsistency issue.

The only issue seems to be if we wanted to support a peek function to
know the buffer to obtain before copying it.

-- Hal