RE: SDP LocIRD and LocORD in Hello & HelloAck msg
"Jim Pinkerton" <[email protected]>
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <E6564B8F86852D46A4E98C485FB33B8F08DE5CD5@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> |
This email slipped through the cracks. Apologies for the long reply time. You are correct that the LocIRD and LocORD are defined from the Local Peer's perspective (i.e. the peer generating the message). In terms of effective requirements, they are different than what you state below. Keep in mind that the sender of an RDMA Read Request must never send more requests than the Inbound RDMA Read Queue Depth at the remote peer or the connection will be torn down. - HelloAck LocIRD >= LocORD in Hello (this allows the Active Peer to increase the LocORD value if it so chooses, up to a maximum of the LocIRD HelloAck value). - HelloAck LocORD <= LocIRD in Hello (this ensures that the Passive Peer will never overflow the receive RDMA Read Queue at the Active Peer). Thus from the Active Peer's perspective, - FinalLocalIRD = LocIRD in Hello message (i.e. any value it wants). - FinalLocalORD <= LocIRD in HelloAck message (this value may change from what was sent in the Hello message, based on what was returned in the HelloAck message). >From the Passive Peer's perspective: - FinalLocalIRD = LocIRD sent in HelloAck message (i.e. any value it wants. They may use the value in Hello message for LocORD as input into what they allocate). - FinalLocalORD <= LocIRD in Hello message. Hope this helps. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Wong, > Isaac M (U.S.A. EUD, SNSL) > Sent: Thursday, April 08, 2004 11:15 AM > To: [email protected] > Subject: [rddp] SDP LocIRD and LocORD in Hello & HelloAck msg > > I am looking for some clarification on the two fields, LocIRD and LocORD > in SDP Hello and HelloAck message as described in > draft-pinkerton-iwarp-sdp-00.txt. > > I believe the description of Hello and HelloAck message in section 6.2.1 > and 6.2.2 is from the perspective of the senders of the messages. If > this is true, then LocIRD in the Hello Message should relate to the > LocORD in the HelloAck Message. Similarly, the LocORD in the Hello > Message should relate to the LocIRD in the HelloAck Message. > > I am not clear if these fields are listed as part of setup negotiation. > I suspect they are. If this is true, then I believe the owner of each of > the read queues should have the final say on the maximum queue length, > and the senders to these queues can advertize a lower number. So, LocORD > in HelloAck <= LocIRD in Hello. LocORD in Hello >= LocIRD in HelloAck. > Thus, FinalLocIRD at Hello sender = FinalLocORD at HelloAck sender = min > (LocIRD in Hello, LocORD in HelloAck); > FinalLocORD at Hello sender = FinalLocIRD at HelloAck sender = min > (LocORD in Hello, LocIRD in HelloAck); > > Is this the way they should be interpreted? > > Isaac Wong > Hewlett Packard > > _______________________________________________ > rddp mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/rddp