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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
