[openib-general] Re: [mgtwg] Payload Length in first RMPP sent segment

[Hal Rosenstock]

Hi Greg,

On Mon, 2005-08-29 at 18:56, Greg Pfister wrote:
> Hal,
> 
> My take is that there's no ambiguity. Then again, I wrote it, so I
> would think that, right? :-)
> 
> The idea is that we're trying to allow *either* of the usual two
> options for specifying a string of stuff: (a) Start out by giving the
> length; or (b) go until you reach a special mark meaning "the end."

The latter being "streaming" mode.

> The thing is it gets complicated when there is only one packet. So
> take two cases: >1 packet, and ==1 packet.

It seems more complicated (perhaps 2 options when there is more than 1
packet).

> length >1 packet: 
> 
> -- PayloadLength <> 0 on 1st packet means case (a). Just read until
> you get that many bytes, which may use only part of the last packet.
> If the last packet isn't also marked last, scream about inconsistency.

So if one is using this option, does the payload length in the 1st
packet reduced by 220 * (number of packets - 1) need to match the
payload length in the last packet ? That's a slightly different
inconsistency from the packet not being marked last but the original
length not exhausted.

> -- PayloadLength=0 on first packet - case (b). Read until you get a
> marked last packet. PayloadLength in that last packet tells you how
> many are valid in that packet (zero in that case -- I'm not sure;
> whole packet, I think).

For SA, wouldn't anything less than 20 would be an error in the last
packet ? If it were 20, it would be legal but an inefficient
implementation (as really the previous packet was full and could have
terminated the RMPP send).

> length ==1 packet meaning RMPPFlags.Last=1 and RMPPFlags.First=1 in
> the same packet. 
> 
> -- Interpretation is the same as the "last packet" case above, i.e.,
> RMPPFlags.Last=1 dominates the interpretation.
> 
> As far as I know, that's it. Any comments from others?
> 
> (This may not forward to openib-general, since I'm not on that list;
> if it doesn't please forward.)

It made it to openib. It's an open list as far as posting goes.

Thanks.

-- Hal

> Greg Pfister
> IBM Distinguished Engineer, Member IBM Academy of Technology
> IBM Systems & Technology Group, Server Technology & Architecture
> (512) 838-8338 | IBM tieline 678-8338 | FAX (512) 838-3418
> Sic Crustulum Frangitur
> 
> Hal Rosenstock <halr at voltaire.com>
> 
> 08/29/2005 08:14 AM
>                To
> mgtwg at infinibandta.org
>                cc
> openib-general at openib.org
>           Subject
> [mgtwg] Payload
> Length in first
> RMPP sent segment
> 
> 
> 
> Hi,
> 
> On the RMPP send side, while the Payload Length field in the last
> segment is clear that it indicates the number of valid bytes in
> Transferred Data, there seems to be some ambiguity in the optional
> Payload Length field in the first segment. I think it can work either
> way but I also think the intent was to reflect the valid bytes. Maybe
> it
> is this way to allow flexibility (choice in the implementation). What
> is
> the correct interpretation ? Should I enter a comment on this ?
> Thanks.
> 
> -- Hal
> 
> IBA 1.2 p.775 line 37
> 
> In the first packet of an RMPP transfer (RMPPFlags.First=1),
> PayloadLength may indicate the sum of the lengths, in bytes, of the
> TransferredData fields in all packets of the entire multipacket
> response; this is done by using a nonzero value for PayloadLength in
> the
> first packet. 
> 
> IBA 1.2 p. 776 line 8
> 
> In the last packet of an RMPP transfer (RMPPFlags.Last=1),
> PayloadLength
> indicates the number of valid bytes in the TransferredData field,
> allowing data transfers that are not an integral multiple of the
> length
> of the TransferredData field. A transfer terminates when either: (a) a
> packet containing RMPPFlags.Last=1 is received; or (b) a nonzero
> PayloadLength was given in the first packet of a transfer, and a
> packet
> is received containing sufficient TransferredData bytes to equal or
> exceed the PayloadLength originally provided. If case (b) occurs and
> RMPPFlags.Last is not 1 for that packet, the Receiver sends an ABORT
> packet with RMPPStatus of "Inconsistent Last and PayloadLength" and
> terminates the transfer.
> 
> 
> 
>