[openib-general] Re: [mgtwg] RMPP Middle Segments Payload Length

[Greg Pfister]

Hal,
I think you're right. The language currently in the spec implies that for 
intermediate packets PayloadLength is ignored on receive, but I don't 
think it anywhere explicitly reconfirms that, as a reserved field, it 
should be set to 0 on transmit.
My take is that, as a result, on that field it wouldn't be as 
straightforward to use the technique we used elsewhere -- have nonzero in 
a previously-reserved field turn on some new optional function.
But I don't think there's any other effect of that spec looseness. And 
using that field for such a purpose, only on intermediate packets, strikes 
me as pretty unlikely.

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> wrote on 08/30/2005 07:50:31 AM:

> Hi Greg,
> 
> In addition to the question about whether the first packet Payload
> Length only includes valid bytes in Transferred Data or all bytes in all
> Transferred Data in all sent segments in the case of a
> multipacket/segment send, there is also a question about the Payload
> Length in middle segments/packets. It looks to me like there is just a
> comment about the Payload Length being valid in first (optional) and
> last (mandatory) segments/packets. So that means it is ignored on
> receive but does it need to be set to 0 on transmit ? It seems possibly
> different from a reserved field in those cases by language in the spec
> but I'm not sure whether this is the case or not.
> 
> Thanks.
> 
> -- Hal
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20050903/bb327e24/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/20050903/bb327e24/attachment.bin>