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

[Greg Pfister]

Hal Rosenstock <halr at voltaire.com> wrote on 08/29/2005 07:40:38 PM:

> 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.
Or C string 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 ?
Yes, if by "match" you mean that the number of bytes indicated in the last 
packet, when added to all the prior bytes, equals the 1st packet's 
PayloadLength. You don't literally have the two PayloadLength fields 
matching bit-for-bit.
> That's a slightly different
> inconsistency from the packet not being marked last but the original
> length not exhausted.
I agreed, you could justifiably argue that it is a different 
inconsistency. However, the error codes built in the spec lump the two 
cases together.

> > -- 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 ? 
Yes.
> 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).
Yes, in streaming / C string mode. No way for the receiver to know it's 
over until it gets the "last packet" code.
In "total count in the first packet" node, I think implementations *shall* 
scream inconsistency if the packet actually containing the last byte isn't 
marked as the last packet.
 
> > 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.

OK. So I guess this one will, too.
 
> Thanks.
> > 
> > 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.



Greg Pfister     http://pfister.userv.ibm.com/
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050904/b195d9ee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5207 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050904/b195d9ee/attachment.bin>