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 <[EMAIL PROTECTED]> > > 08/29/2005 08:14 AM > To > [EMAIL PROTECTED] > cc > [email protected] > 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. > > > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
