Transport layer retries for targets

Day, Brian Brian.Day at lsil.com
Wed Sep 14 15:41:17 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsil.com>
*
Randy...

I do not believe you are referring to a valid balance point as defined in
section 9.2.6.3.3.4 of the latest SAS 1.1 rev 9e.
A balance point would be where there are no outstanding ACKs for any frames
transmitted.... the spec describes it more precisely than that.

In the example I believe you are suggesting, the target is sending the data
frames as non-interlocked, and sending them back to back without waiting for
the corresponding ACKs.  In this case, the most recent balance point is
before frame A, not after C.
So when it has the ACK/NAK timeout, it would need to resend starting at
frame A again.

The transport retries does handle the frames being lost as well.

Brian
 

-----Original Message-----
From: Randy Chapman [mailto:Randy_Chapman at pmc-sierra.com] 
Sent: Wednesday, September 14, 2005 3:58 PM
To: t10 at t10.org
Subject: RE: Transport layer retries for targets

* From the T10 Reflector (t10 at t10.org), posted by:
* Randy Chapman <Randy_Chapman at pmc-sierra.com>
*
Hi Brian and Dave,

Consider the case where target sends A,B,C,D read DATA frames and, say, C
gets lost. Am I correct that the transport layers in fact can not recover
properly from this? Reason being, initiator sends 3 acks back to target,
target times out waiting for the 4th and thinks that the ack/nak balance
point is C, retransmits D. But, C was lost, not D. In this case higher
layers on the initiator have to re-issue the read command to recover. Make
sense?

Randy Chapman
PMC-Sierra Inc.

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Sluiter,
David
Sent: Wednesday, September 14, 2005 1:26 PM
To: Sluiter, David; t10 at t10.org
Subject: RE: Transport layer retries for targets


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sluiter, David" <dsluiter at exabyte.com>
*
Hi Brian,

Thanks for your reply.

Just to be clear, in my second question I meant that the target had received
3 ACKS for frames A, B & D (ACK for frame C was lost) which the target sees
as ACKs for frames A, B & C (ACKs a, b & c), so the balance point for the
target is frame D, which is the one it should resend with correct DATAOFFSET
and CHANGING DATA POINTER set.

So anyways, what you're saying is that it doesn't matter to the initiator
that the ACKs are out of sync. The initiator relies on the DATAOFFSET value
and CHANGING DATA POINTER bit to straighten out its buffer, which is cool.

Thanks,
Dave Sluiter
Exabyte
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org





More information about the T10 mailing list