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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.