>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 >?
The receiving side doesn't perform a data copy. It collects the separate MAD buffers together in a list and hands those to the user. The length for a data buffer that would needed to copy the received data into a single data buffer is set in struct ib_mad_recv_wc mad_len. The call ib_coalesce_recv_mad() is intended to perform the data copy for the user, but isn't implemented yet. >> 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 ? I was referring to streaming sends. The issue is that there would need to be a way to join together multiple send requests together as a single transfer. I haven't given this much thought. I guess one way to support something like this is to conceptually have some sort of send_id that is used to associate multiple send requests. Multiple calls to ib_post_send_mad could chain the requests together until the transfer is complete... >> > 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. See above... this is known before any data copying is done. - 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
