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

[Sean Hefty]

>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