<br><font size=2><tt>Hal Rosenstock <halr@voltaire.com> wrote on
08/29/2005 07:40:38 PM:<br>
<br>
> Hi Greg,<br>
> <br>
> On Mon, 2005-08-29 at 18:56, Greg Pfister wrote:<br>
> > Hal,<br>
> > <br>
> > My take is that there's no ambiguity. Then again, I wrote it,
so I<br>
> > would think that, right? :-)<br>
> > <br>
> > The idea is that we're trying to allow *either* of the usual
two<br>
> > options for specifying a string of stuff: (a) Start out by giving
the<br>
> > length; or (b) go until you reach a special mark meaning "the
end."<br>
> <br>
> The latter being "streaming" mode.</tt></font>
<p><font size=2><tt>Or C string mode.<br>
 <br>
> > The thing is it gets complicated when there is only one packet.
So<br>
> > take two cases: >1 packet, and ==1 packet.<br>
> <br>
> It seems more complicated (perhaps 2 options when there is more than
1<br>
> packet).<br>
> <br>
> > length >1 packet: <br>
> > <br>
> > -- PayloadLength <> 0 on 1st packet means case (a). Just
read until<br>
> > you get that many bytes, which may use only part of the last
packet.<br>
> > If the last packet isn't also marked last, scream about inconsistency.<br>
> <br>
> So if one is using this option, does the payload length in the 1st<br>
> packet reduced by 220 * (number of packets - 1) need to match the<br>
> payload length in the last packet ?</tt></font>
<p><font size=2><tt>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.</tt></font>
<p><font size=2><tt>> That's a slightly different<br>
> inconsistency from the packet not being marked last but the original<br>
> length not exhausted.</tt></font>
<p><font size=2><tt>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.<br>
<br>
> > -- PayloadLength=0 on first packet - case (b). Read until you
get a<br>
> > marked last packet. PayloadLength in that last packet tells you
how<br>
> > many are valid in that packet (zero in that case -- I'm not sure;<br>
> > whole packet, I think).<br>
> <br>
> For SA, wouldn't anything less than 20 would be an error in the last<br>
> packet ? </tt></font>
<p><font size=2><tt>Yes.</tt></font>
<p><font size=2><tt>> If it were 20, it would be legal but an inefficient<br>
> implementation (as really the previous packet was full and could have<br>
> terminated the RMPP send).</tt></font>
<p><font size=2><tt>Yes, in streaming / C string mode. No way for the receiver
to know it's over until it gets the "last packet" code.</tt></font>
<p><font size=2><tt>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.<br>
 <br>
> > length ==1 packet meaning RMPPFlags.Last=1 and RMPPFlags.First=1
in<br>
> > the same packet. <br>
> > <br>
> > -- Interpretation is the same as the "last packet"
case above, i.e.,<br>
> > RMPPFlags.Last=1 dominates the interpretation.<br>
> > <br>
> > As far as I know, that's it. Any comments from others?<br>
> > <br>
> > (This may not forward to openib-general, since I'm not on that
list;<br>
> > if it doesn't please forward.)<br>
> <br>
> It made it to openib. It's an open list as far as posting goes.<br>
</tt></font>
<p><font size=2><tt>OK. So I guess this one will, too.</tt></font>
<p><font size=2><tt> <br>
> Thanks.<br>
> > <br>
> > Hal Rosenstock <halr@voltaire.com><br>
> > <br>
> > 08/29/2005 08:14 AM<br>
> >                To<br>
> > mgtwg@infinibandta.org<br>
> >                cc<br>
> > openib-general@openib.org<br>
> >           Subject<br>
> > [mgtwg] Payload<br>
> > Length in first<br>
> > RMPP sent segment<br>
> > <br>
> > <br>
> > <br>
> > Hi,<br>
> > <br>
> > On the RMPP send side, while the Payload Length field in the
last<br>
> > segment is clear that it indicates the number of valid bytes
in<br>
> > Transferred Data, there seems to be some ambiguity in the optional<br>
> > Payload Length field in the first segment. I think it can work
either<br>
> > way but I also think the intent was to reflect the valid bytes.
Maybe<br>
> > it<br>
> > is this way to allow flexibility (choice in the implementation).
What<br>
> > is<br>
> > the correct interpretation ? Should I enter a comment on this
?<br>
> > Thanks.<br>
> > <br>
> > -- Hal<br>
> > <br>
> > IBA 1.2 p.775 line 37<br>
> > <br>
> > In the first packet of an RMPP transfer (RMPPFlags.First=1),<br>
> > PayloadLength may indicate the sum of the lengths, in bytes,
of the<br>
> > TransferredData fields in all packets of the entire multipacket<br>
> > response; this is done by using a nonzero value for PayloadLength
in<br>
> > the<br>
> > first packet. <br>
> > <br>
> > IBA 1.2 p. 776 line 8<br>
> > <br>
> > In the last packet of an RMPP transfer (RMPPFlags.Last=1),<br>
> > PayloadLength<br>
> > indicates the number of valid bytes in the TransferredData field,<br>
> > allowing data transfers that are not an integral multiple of
the<br>
> > length<br>
> > of the TransferredData field. A transfer terminates when either:
(a) a<br>
> > packet containing RMPPFlags.Last=1 is received; or (b) a nonzero<br>
> > PayloadLength was given in the first packet of a transfer, and
a<br>
> > packet<br>
> > is received containing sufficient TransferredData bytes to equal
or<br>
> > exceed the PayloadLength originally provided. If case (b) occurs
and<br>
> > RMPPFlags.Last is not 1 for that packet, the Receiver sends an
ABORT<br>
> > packet with RMPPStatus of "Inconsistent Last and PayloadLength"
and<br>
> > terminates the transfer.<br>
<br>
</tt></font>
<p><font size=2 face="sans-serif"><br>
Greg Pfister     http://pfister.userv.ibm.com/<br>
IBM Distinguished Engineer, Member IBM Academy of Technology<br>
IBM Systems & Technology Group, Server Technology & Architecture<br>
(512) 838-8338 | IBM tieline 678-8338 | FAX (512) 838-3418<br>
Sic Crustulum Frangitur</font>